Day One Deploying SRX Gateways - Juniper Networkspdf
Day One Deploying SRX Gateways - Juniper Networkspdf
Day One Deploying SRX Gateways - Juniper Networkspdf
By Barny Sanchez
Junos® Dynamic Services Series
“The SRX is an extremely feature rich product and may give users
pause when getting started. This Day One book allows the user to get
up and running quickly into the wonderful world of Junos.”
Rob Cameron, Technical Marketing Engineering Manager, Data Center SRX, Juniper Networks
Day One: Deploying SRX Series Services Gateways shows you how to:
• Understand the different ways to manage the SRX Series Services Gateways.
• Console to a SRX device for the first time and start the initial boot process.
• Review operational and configuration modes.
• Review interfaces, security zones, and security policies.
• Configure basic IP connectivity and elements to enable remote access.
• Configure basic static routing.
• Upgrade the firmware of the SRX device.
• Configure different levels of local administration and external administrators.
• Configure additional network and system management resources.
• Write basic security policies.
• Configure different NAT source scenarios.
• Import the SRX devices into NSM.
• Enable different logging and troubleshooting tools.
Juniper Networks Day One books provide just the information you need on day one. They are
written by subject matter experts and engineers who specialize in getting networks up and running.
Look for other titles covering high-performance networking solutions at www.juniper.net/dayone.
This book is available in a variety of print and digital formats.
7100126
Junos Dynamic Services Series
®
By Barny Sanchez
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
ii
© 2010 by Juniper Networks, Inc. All rights reserved. About the Author
Barny Sanchez (JNCIE FW/VPN #1, JNCIS-SSL,
Juniper Networks, the Juniper Networks logo, Junos, JNCIS-ER, JNCIS-M, JNCIS-SEC, JNCIA-IDP,
NetScreen, and ScreenOS are registered trademarks of JNCIA-AC, JNCIA-EX, JNCIA-WX, JNCIA-DX, JCNA,
Juniper Networks, Inc. in the United States and other JNCI) holds a BS of Science in Information Systems
countries. Junose is a trademark of Juniper Networks, Security from Westwood College, has completed
Inc. All other trademarks, service marks, registered advanced studies in Electronics Engineering from the
trademarks, or registered service marks are the property Instituto Tecnologico de Costa Rica, and is currently
of their respective owners. undertaking a Master’s degree in Information Assurance
and Security at Capella University. He is a Consulting
Juniper Networks assumes no responsibility for any Engineer at Juniper Networks, specializing in Security
inaccuracies in this document. Juniper Networks reserves Products and Solutions. Prior to this role, Barny worked
the right to change, modify, transfer, or otherwise revise as a Sr. Systems Engineer supporting Juniper Networks
this publication without notice. Products made or sold by Strategic Partners, and before that, he spent over two
Juniper Networks or components thereof might be years as a Senior Instructor, teaching most of Juniper's
covered by one or more of the following patents that are products. Before joining Juniper, Barny occupied
owned by or licensed to Juniper Networks: U.S. Patent management positions at different technical support
Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, organizations for Intel Corporation and Cisco Systems,
6,333,650, 6,359,479, 6,406,312, 6,429,706, in addition to spending several years designing and
6,459,579, 6,493,347, 6,538,518, 6,538,899, implementing multi-vendor networks for customers
6,552,918, 6,567,902, 6,578,186, and 6,590,785. around the globe.
Version History: v1 August 2010 This book is available in a variety of formats at: www.
2 3 4 5 6 7 8 9 10 juniper.net/dayone. Send your suggestions, comments,
and critiques by email to dayone@juniper.net.
iii
The SRX
The SRX Series Services Gateway is a mouthful to pronounce. And the
security device comes in several different platforms designed for a
variety of networking uses. There are “small” SRX Series Services
Gateways and there are “large” SRX Series Services Gateways.
This book simplifies the terminology by using the generic term SRX, or
the SRX.
What ports can you use? That’s really up to your management require-
ments, but basically any port, or all ports, can be configured to accept
management connections. Since you are now dealing with an IP
connection, you can directly attach using a standard Ethernet patch
cable, or you can also be thousands of miles away (provided, of
course, that you can reach the configured IP address).
Typically, after doing an initial configuration via the console, most
administrators configure the necessary elements to allow remote access
to the device via protocols like SSH and telnet. There are several steps
to enable remote access management via the CLI, and these are shown
in subsequent chapters of this book.
Since the interface is the same as when you connect via the console,
when managing the device you can enjoy the same unlimited power
with some added benefits, the most important being the ability to
accept multiple, concurrent administration connections, via the same
ports.
TIP Using the J-Web is sometimes the preferred connection method for
administrators that are accustomed to managing other vendors’
devices via graphical interfaces.
In terms of limitations, the NSM is not suitable for tasks like debug-
ging, but on the other hand, it is a good solution for logging events,
and keeping your network in optimal condition. It is unquestionable
that the power of NSM and all of its features far outweighs its few
limitations.
MORE? There is so much more to NSM than what’s discussed in these few
paragraphs. If you want to learn more about it, start by reviewing the
product specifics from the Juniper Networks website at www.juniper.
net/us/en/products-services/network-management/. Training informa-
tion is available at www.juniper.net/us/en/training/technical_educa-
tion/.
To connect via the console you need: the supplied console cable that
came with the SRX device, a computer with a serial port (or USB to
Serial adapter), and a terminal emulation application running on the
computer.
10 Day One: Deploying SRX Series Services Gateways
TIP If you are an Apple user you’re not out of luck. Connecting to the
console of your device is just as easy. After connecting your USB-to-
Serial adapter, find out what the name of the devices is (“$ ls /dev/”),
and once you know this, open a terminal window and type “$ screen /
dev/[device_name] 9600”.
ORJLQ
Chapter 1: Different Ways to Manage an SRX 11
In the event that the SRX has some configuration already committed
(maybe this is not a new device), then the prompt is different. The
prompt possibilities are many, depending whether the committed
configuration has a banner or not, for example, but the key thing is
that the word $PQHVLDF will not be there. An example:
VU[WW\X
ORJLQ
If you have made it this far and can’t wait any longer, dive in! You may
log in to the SRX by using the login name URRW and pressing [Enter] for
the password. If you do you will see something similar to this:
-81265EXLOW87&
URRW#
Plenty of Day One books and additional online and printed resources
cover general Junos operations, so you may be wondering why we do
so again here.
Running Junos on a security device shifts the perspective from connec-
tivity that includes security (unless strictly prohibited to) rather than
excludes security (unless strictly permitted). This dramatic shift in
posture means that Junos approaches connectivity in several different
ways on the SRX Series. Junos makes any decision with security, not
connectivity, as its primary objective.
For example, an EX Series or MX Series configured with an interface
IP address and system services, immediately supports connectivity to
other devices; while the SRX Series requires additional configuration
steps.
So this chapter, covers not the details of operation and configuration
modes that you are already know, but the aspects that set the SRX
apart from M/MX/T routers and EX switches. (If you are wondering
about the J-series routers, these started running the same Junos flavor
available in SRXs since early 9.x versions.)
In Figure 2.1 you can see that traffic destined to an interface can be one
of three different types:
management (or system-services), for example ping and SSH.
protocol-related such as OSPF and DHCP (or referred to simply as
protocol).
user data traffic, such as packets corresponding to the communi-
cation from a client to a server.
Notice that if traffic is destined to an interface for the purpose of
managing the device, then this is where host-inbound-traffic comes
into play. Host-inbound-traffic can be configured at two different
levels. If configured at the zone level, then it will affect all the interfaces
16 Day One: Deploying SRX Series Services Gateways
bound to that zone, but when configured at the interface level host-
inbound-traffic will affect only that specific interface. In the event that
host-inbound-traffic is configured at both the interface and zone levels,
then the interface settings will take precedence. In other words, services
are not added.
NOTE As you can see, this can be a little tricky. Let’s try another example. If
you configure ping system-services at the zone level, and try to ping an
interface belonging to that zone, it will respond properly. If you later
decide to enable telnet in the same interface by configuring system-
services at the interface level, then ping will stop responding. This is
because interface settings take precedence. To fix this and be able to
get responses again, you need to enable ping system-services at the
interface level.
TIP If you want to apply policies to fxp0 interfaces and need to do things
like permitting only certain subnets to connect, then you want to
explore the SRX’s use of filters. Keep this in mind, as the functionality
is discussed soon.
hole (drop) the traffic. This specific behavior is what it makes the SRX
so secure by nature, but a little different than other Junos operating
devices; you decide what specific traffic is permitted from one zone to
another.
Be aware that traffic moving from any zone to any other zone, implies
that this is user data or transiting traffic (referred to many times as
transient traffic). Since management traffic is not traversing the firewall
but is actually terminating at the firewall, then this does not require
examination by any security policies.
Finally, the outer layer of Figure 2.1, the router, makes reference to the
routing table instance. By default, all predefined zones or newly created
zones are bound to the routing instance LQHW (IPv4 routing table),
unless specified otherwise. Put differently, configuring an IP address in
an interface, and binding it to a zone, creates a host routing entry table
in LQHW.
So where do you configure all of these elements? Junos is fairly forth-
right here:
Interfaces are configured under the >HGLWLQWHUIDFHV@hierarchy
Zones and host-inbound-traffic settings are configured under
the>HGLWVHFXULW\]RQHV@hierarchy
Policies are configured under the >HGLWVHFXULW\SROLFLHV@
hierarchy
And, system services are configured under the >HGLWV\VWHP
VHUYLFHV@hierarchy
Display the different configuration blocks discussed in both this and the previous section (try
alternating the commands below and making use of pipes | display set | no-more):
!VKRZFRQILJXUDWLRQ
!VKRZFRQILJXUDWLRQVHFXULW\
!VKRZFRQILJXUDWLRQV\VWHPVHUYLFHV
!VKRZFRQILJXUDWLRQLQWHUIDFHV
Also in Figure 2.2, note how the branch has Internet access via the
head-end device.
Pay special attention to the delimitation of areas (trust, untrust,
admins) as these highlight the concepts of zones presented earlier, and
note in the case of the NSM and RADIUS servers, there is no zone
allocation, since these services are connected via the fxp0 interface.
From a management perspective, it’s not always the case that all
services are directly attached to the fxp0 interface, and, like this sample
network, an intermediate hop is used to reach a larger management
network where many devices play an important role in the administra-
tion and monitoring tasks. Both 10.189.x.y/27 subnets belong to a
larger network, 10.188.0.0/14. This is important to note since it can
simplify the routing configuration.
Throughout this book we’ll delve into more material, concrete scenari-
os and configuration steps that are based on this network topology and
presented to you to try on your equipment. Let’s get going, now, and
establish remote access.
Chapter 3
-81265EXLOW87&
URRW#FOL
URRW!HGLW
(QWHULQJFRQILJXUDWLRQPRGH
>HGLW@
URRW
NOTE By the way, the ping service was not forgotten. It is turned on by
default for fxp0, but needs explicit configuration for all other inter-
faces, something that will is addressed in the next section. Also, ping
cannot be activated under system services.
24 Day One: Deploying SRX Series Services Gateways
TIP If you are following along and trying these examples on your device,
you may want to leave the console connection opened while reviewing
the next section.
To Configure Interfaces:
1. While still connected to the console as root, enter configuration
mode:
URRW!HGLW
(QWHULQJFRQILJXUDWLRQPRGH
>HGLW@
URRW
The output confirms that both the Admin and Link of the interfaces
are operational.
To Configure Zones:
1. While still connected to the console as root, enter configuration
mode:
URRW!HGLW
(QWHULQJFRQILJXUDWLRQPRGH
>HGLW@
URRW
URRWVHWVHFXULW\]RQHVVHFXULW\]RQHXQWUXVWLQWHUIDFHVJH
>HGLW@
URRWVHWVHFXULW\]RQHVVHFXULW\]RQHXQWUXVWLQWHUIDFHVJH
BEST PRACTICES Always configure zones from the perspective of the firewall that you
are setting, not from the perspective of the other devices in the net-
work. For example, notice that in this example you do not need to
configure the zone trust, as this is irrelevant and can even be unknown
from the perspective of the administrator configuring the SRX3400.
Also notice that both ge-0/0/1 and ge-0/0/2 belong to the same security
zone. There are virtually no limits on what zones you may bind
interfaces to, but an interface can only be bound to one zone at any
given time.
BEST PRACTICES Acknowledging the fact that this is a document for security adventur-
ists, telnet and FTP are inherently insecure protocols that offer no data
protection. So, before turning these services on in your devices,
analyze your need for them. If you absolutely have to configure them,
try to do so on the internal side, never on interfaces facing public
networks. In this instance we are setting aside best practices only for
instructional purposes.
URRW!VKRZURXWH
LQHWGHVWLQDWLRQVURXWHVDFWLYHKROGGRZQ
KLGGHQ
$FWLYH5RXWH /DVW$FWLYH
%RWK
>6WDWLF@
!WRYLDJH
>6WDWLF@G
!WRYLDI[S
>'LUHFW@G
!YLDI[S
>/RFDO@G
/RFDOYLDI[S
>'LUHFW@G
!YLDJH
>/RFDO@G
/RFDOYLDJH
>'LUHFW@G
!YLDJH
>/RFDO@G
Chapter 3: Enabling Remote Access 29
/RFDOYLDJH
>'LUHFW@G
!YLDJH
>/RFDO@G
/RFDOYLDJH
You can confirm that the file was copied by using the Junos CLI:
URRW!ILOHOLVW
FIURRW
FVKUF
KLVWRU\
ORJLQ
SURILOH
VVK
MXQRVVU[5GRPHVWLFWJ]
URRW!
Chapter 4
Configuring Administrators
Only the root administrator can connect to the SRX via the configura-
tion we’ve implemented. This can be problematic, especially if more
than one person needs to connect to the SRX. Sharing the root
account among multiple users creates several difficulties: there is no
way to account for who really logged in and made changes (hopefully
the changes won’t disrupt network operations); this one account has
unlimited powers, and there is virtually nothing the root account
cannot do (any administrator can cause a lot of headaches if he or she
inadvertently deletes or modifies the configuration); and troubleshoot-
ing and monitoring are an issue.
In this chapter let’s configure local and remote administrator accounts
with different privileges. Local accounts exist only in the device where
they’re configured, and this is ideal when a handful of individuals
connect to the SRX. If dozens of administrators, or even more,
connect to these devices, like in a NOC (Network Operations Center)
or a large enterprise, then you are better off leveraging the centralized
authentication mechanisms offered by RADIUS or TACACS+.
To demonstrate the flexibility of Junos, three local accounts will be
configured with the following privileges:
barnys (super-user)
halle (read-only)
and, max (operator)
A fourth account, carrie, has a more complex set of requirements,
allowing her to change only interface settings.
The same requirements are configured using RADIUS. This book
does not offer insight into the theory and operation of RADIUS, it
simply explains how to configure the requirements presented. The
Appendix, however, shows screenshots taken when the server used for
the examples in this book was being configured, and is something that
may be useful for the administrator that needs to integrate RADIUS
with Active Directory. This is a trivial task using Juniper’s Steel Belted
Radius (SBR) product. For more details of this product refer to the
following link: http://www.juniper.net/us/en/products-services/
software/ipc/sbr-series/enterprise/.
NOTE Another option exists using TACACS+, but it is not discussed in this
short book. If this is your only option, please refer to the SRX techni-
cal documentation at www.juniper.net/techpubs/.
Chapter 4: Configuring Administrators 33
>HGLW@
URRWVHWV\VWHPORJLQXVHUPD[FODVVRSHUDWRUDXWKHQWLFDWLRQSODLQWH[WSDVVZRUG
1HZSDVVZRUG
5HW\SHQHZSDVVZRUG
>HGLW@
URRWVHWV\VWHPORJLQXVHUKDOOHFODVVUHDGRQO\DXWKHQWLFDWLRQSODLQWH[WSDVVZRUG
1HZSDVVZRUG
5HW\SHQHZSDVVZRUG
>HGLW@
URRWVHWV\VWHPORJLQXVHUEDUQ\VFODVVVXSHUXVHUDXWKHQWLFDWLRQSODLQWH[WSDVVZRUG
1HZSDVVZRUG
5HW\SHQHZSDVVZRUG
2. Create a local class consultant with restricted access to configure
interfaces only:
>HGLW@
URRWVHWV\VWHPORJLQFODVVFRQVXOWDQWDOORZFRQILJXUDWLRQLQWHUIDFHV
>HGLW@
URRWVHWV\VWHPORJLQFODVVFRQVXOWDQWSHUPLVVLRQVFRQILJXUH
3. Configure the user carrie and assign this to the class consultant:
>HGLW@
EDUQ\VVHWV\VWHPORJLQXVHUFDUULHFODVVFRQVXOWDQWDXWKHQWLFDWLRQSODLQWH[WSDVVZRUG
1HZSDVVZRUG
5HW\SHQHZSDVVZRUG
VERIFY Take a moment to verify that your accounts are working as expected.
Understanding what to expect from every class is critical to mitigating
many management problems in your network. Here, only max, halle
and carrie are verified as the account barnys is not any different than
the root account used so far.
PD[!VKRZFRQILJXUDWLRQ
/DVWFRPPLW87&E\EDUQ\V
YHUVLRQ
$&&(66'(1,('
V\VWHP^
$&&(66'(1,('
`
LQWHUIDFHV^
$&&(66'(1,('
`
URXWLQJRSWLRQV^
$&&(66'(1,('
`
VHFXULW\^
$&&(66'(1,('
`
PD[!FOHDULQWHUIDFHVVWDWLVWLFVDOO
PD[!WUDFHURXWH
WUDFHURXWHWRKRSVPD[E\WHSDFNHWV
PVPVPV
PVPVPV
PVPVPV
PD[!SLQJFRXQW
3,1*GDWDE\WHV
E\WHVIURPLFPSBVHT WWO WLPH PV
E\WHVIURPLFPSBVHT WWO WLPH PV
SLQJVWDWLVWLFV
SDFNHWVWUDQVPLWWHGSDFNHWVUHFHLYHGSDFNHWORVV
URXQGWULSPLQDYJPD[VWGGHY PV
Notice how the user max that was assigned to the class operator
cannot make configuration changes (he simply cannot go into configu-
ration mode), or read the configuration. He can, however, clear
interface statistics, and run traceroutes, pings, or diagnostics com-
mands. This is the behavior expected of this class.
5. Test the user account halle:
>EDUQ\V#VHUYHUa@VVKKDOOH#
KDOOH#·VSDVVZRUG
-81265EXLOW87&
KDOOH!FRQILJXUH
A
XQNQRZQFRPPDQG
KDOOH!FOHDU
A
XQNQRZQFRPPDQG
KDOOH!SLQJ
A
XQNQRZQFRPPDQG
KDOOH!VKRZFRQILJXUDWLRQ
/DVWFRPPLW87&E\EDUQ\V
YHUVLRQ
$&&(66'(1,('
36 Day One: Deploying SRX Series Services Gateways
KDOOH!VKRZV\VWHPXSWLPH
&XUUHQWWLPH87&
6\VWHPERRWHG87&ZGDJR
3URWRFROVVWDUWHG87&ZGDJR
/DVWFRQILJXUHG87&DJRE\EDUQ\V
$0XSGD\VXVHUVORDGDYHUDJHV
KDOOH!VKRZLQWHUIDFHVI[S
3K\VLFDOLQWHUIDFHI[S(QDEOHG3K\VLFDOOLQNLV8S
VQLS!
The account halle is restricted to operational mode show commands.
She cannot clear interfaces or run applications. The class read-only is
good for administrators in charge of monitoring the device’s opera-
tional status.
6. Test the user account carrie:
>EDUQ\V#VHUYHUa@VVKFDUULH#
FDUULH#·VSDVVZRUG
-81265EXLOW87&
FDUULH!VKRZ
A
XQNQRZQFRPPDQG
FDUULH!HGLW
(QWHULQJFRQILJXUDWLRQPRGH
8VHUVFXUUHQWO\HGLWLQJWKHFRQILJXUDWLRQ
EDUQ\VWHUPLQDOSSLGRQVLQFH87&LGOH
>HGLW@
>HGLW@
FDUULHVKRZ
/DVWFKDQJHG87&
LQWHUIDFHV^
JH^
XQLW^
IDPLO\LQHW^
DGGUHVV
`
`
`
JH^
XQLW^
IDPLO\LQHW^
DGGUHVV
`
Chapter 4: Configuring Administrators 37
`
`
JH^
XQLW^
IDPLO\LQHW^
DGGUHVV
`
`
`
I[S^
XQLW^
IDPLO\LQHW^
DGGUHVV
`
`
`
`
>HGLW@
FDUULHHGLWLQWHUIDFHVI[S
>HGLWLQWHUIDFHVI[S@
FDUULHVHWGHVFULSWLRQ´&RQQHFWVWRIRUPDQDJHPHQWRQO\µ
>HGLWLQWHUIDFHVI[S@
FDUULHFRPPLWDQGTXLW
FRPPLWFRPSOHWH
([LWLQJFRQILJXUDWLRQPRGH
TIP Now that every user has unique accounts, you can see exactly what
the different administrators typed when they connected, something
that was not possible if everyone was sharing the same root account.
The factory default configuration has enabled the logging of interac-
tive commands, and you can see the log with the VKRZORJLQWHUDF
WLYHFRPPDQGVcommand. This is a very powerful forensics tool.
URRW#·VSDVVZRUG
>EDUQ\V#VHUYHUa@VVKURRW#
URRW#·VSDVVZRUG
-81265EXLOW87&
URRW#FOL
URRW!FRQILJXUH
(QWHULQJFRQILJXUDWLRQPRGH
>HGLW@
URRWGHOHWHV\VWHPORJLQXVHUEDUQ\V
>HGLW@
URRWGHOHWHV\VWHPORJLQXVHUPD[
>HGLW@
URRWGHOHWHV\VWHPORJLQXVHUKDOOH
>HGLW@
URRWGHOHWHV\VWHPORJLQXVHUFDUULH
>HGLW@
URRWFRPPLW
FRPPLWFRPSOHWH
By the way, the user class consultant remains intact as you need it to
for the radius authorization.
There are different approaches for the configuration of the RADIUS
authentication and authorization components, and you should choose
your approach based on your infrastructure and how versed you are in
the RADIUS server side. Here are two approaches that will hopefully
be of use.
The first approach consists of configuring the user classes locally in
the SRX and using RADIUS exclusively for authentication purposes.
This works well, but if there are hundreds or thousands of devices in
your network, then you run into the risk of decentralizing the authori-
zation process. So, for example, if you create the class consultant like
in the previous example, and if by mistake you don’t configure it
exactly the same way in all of the devices, then you can cause a major
headache. Make sure that you clearly understand that the authentica-
tion comes from the RADIUS server in this approach, whereas the
authorization (what the user can do) comes from the locally defined
classes.
Chapter 4: Configuring Administrators 39
WARNING Don’t lock yourself out! When you configure the authentication order
only to RADIUS, this means that the local user database will only be
checked if the SRX cannot establish a communication with the RA-
DIUS server (i.e., server is down). When you configure the authentica-
tion order as in the example, this gives you the possibility of connecting
with local user accounts (like root), in the event that the server can be
reached, but your account is not properly configured in the RADIUS
system. In other words, configure it as in the example, so you always
have a back-door entry in case something goes wrong on the server
side.
Configure the server. Remember that the secret password (in this case
secret123) has to be shared by the SRX and the RADIUS server (refer
to the Figure 2.2 for the location and information of the server):
>HGLW@
URRWVHWV\VWHPUDGLXVVHUYHUVHFUHWVHFUHW
>HGLW@
URRWVHWV\VWHPORJLQXVHUPD[IXOOQDPH´2SHUDWRUULJKWVµFODVVRSHUDWRU
>HGLW@
URRWVHWV\VWHPORJLQXVHUKDOOHIXOOQDPH´5HDGRQO\ULJKWVµFODVVUHDGRQO\
>HGLW@
URRWVHWV\VWHPORJLQXVHUFDUULHIXOOQDPH´&RQVXOWDQWULJKWVµFODVVFRQVXOWDQW
>HGLW@
URRWFRPPLW
FRPPLWFRPSOHWH
>HGLW@
Be clear about this last step: neither the previous user accounts nor the
class consultant are needed any longer, since the RADIUS server
provides both.
2. Create a user to be used as a connection template for all RADIUS
users:
Chapter 4: Configuring Administrators 41
>HGLW@
URRWVHWV\VWHPORJLQXVHUUHPRWHIXOOQDPH´5DGLXVXVHUWHPSODWHµFODVVXQDXWKRUL]HG
>HGLW@
URRWFRPPLW
FRPPLWFRPSOHWH
The use of the class unauthorized here may seem strange. When you
configure a new user you have to specify a class, otherwise Junos does
not let you commit, and unauthorized is in essence a class with no
permissions, since the actual permissions are being passed in the form
of RADIUS attributes from the server. Notice what happens if you
attempt to configure a user with no class definition:
>HGLW@
URRWVHWV\VWHPORJLQXVHUUHPRWHIXOOQDPH´5DGLXVXVHU
WHPSODWHµ
>HGLW@
URRWVKRZV\VWHPORJLQ
XVHUUHPRWH^
IXOOQDPH´5DGLXVXVHUWHPSODWHµ
XLG
FODVVXQDXWKRUL]HG
`
XVHUUHPRWH^
IXOOQDPH´5DGLXVXVHUWHPSODWHµ
:DUQLQJPLVVLQJPDQGDWRU\VWDWHPHQWV¶FODVV·
`
>HGLW@
URRWFRPPLW
>HGLWV\VWHPORJLQ@
¶XVHUUHPRWH·
0LVVLQJPDQGDWRU\VWDWHPHQW¶FODVV·
HUURUFRPPLWIDLOHGPLVVLQJVWDWHPHQWV
>HGLW@
URRWUROOEDFN
ORDGFRPSOHWH
42 Day One: Deploying SRX Series Services Gateways
Configuring NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Configuring DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Configuring SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Configuring Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
44 Day One: Deploying SRX Series Services Gateways
Configuring NTP
You are encouraged to configure NTP as soon as possible and for a
variety of reasons. From the perspective of this book, it would be very
beneficial to learn not only who the administrators that log in are, but
also when they log in. NTP is necessary to stamp logs, which can help
in troubleshooting tasks. Also, logging is often configured within
various security policies, so that you can track the creation and tear
down of sessions.
The process of configuring NTP is straightforward, and consists
basically of telling the SRX where the NTP server is, adjusting the
connection parameters (optional), changing the clock, and testing that
the time is being updated properly.
>HGLW@
URRWVHWV\VWHPQWSERRWVHUYHU
>HGLW@
URRWVHWV\VWHPWLPH]RQH$PHULFD1HZB<RUN
Chapter 5: Configuring Network and System Management 45
NOTE If you don’t have an NTP server already in place in your local network,
you can use a publicly available one. For a reference to public NTP
servers visit the following NIST website: http://tf.nist.gov/tf-cgi/
servers.cgi.
Note that the difference in our NTP configuration is that the boot-
server option is only referenced by Junos upon boot-time. Once the
system has fully restored, then it uses the other server specified in the
first entry above. So these servers can be different, although they are
not in this example.
URRW!VHWGDWHQWS
-XQQWSGDWH>@VWHSWLPHVHUYHURIIVHWVHF
46 Day One: Deploying SRX Series Services Gateways
URRW!VKRZQWSDVVRFLDWLRQV
UHPRWHUHILGVWWZKHQSROOUHDFKGHOD\RIIVHWMLWWHU
$&76
Configuring DNS
Having DNS configured is essential for creating rules, when trouble-
shooting, and also so that automatic updates and downloads of
different SRX services, like IPS, work properly. Now is a good time to
get it done.
You can enable the SRX to perform DNS lookups during the configu-
ration process, but it’s also possible to specify the domain name and an
appendix, so that you can resolve hosts in your network without fully
qualifying them.
>HGLW@
URRWVHWV\VWHPGRPDLQQDPHFDPODEMXQLSHUQHW
4. Commit and test (refer to Figure 2.2 for internal device names):
>HGLW@
URRWFRPPLW
FRPPLWFRPSOHWH
>HGLW@
URRWUXQSLQJFRXQWMXQLSHUQHW
3,1*MXQLSHUQHWGDWDE\WHV
E\WHVIURPLFPSBVHT WWO WLPH PV
E\WHVIURPLFPSBVHT WWO WLPH PV
E\WHVIURPLFPSBVHT WWO WLPH PV
MXQLSHUQHWSLQJVWDWLVWLFV
SDFNHWVWUDQVPLWWHGSDFNHWVUHFHLYHGSDFNHWORVV
URXQGWULSPLQDYJPD[VWGGHY PV
>HGLW@
URRWUXQSLQJFRXQWUDGLXV
3,1*UDGLXVFDPODEMXQLSHUQHWGDWDE\WHV
E\WHVIURPLFPSBVHT WWO WLPH PV
E\WHVIURPLFPSBVHT WWO WLPH PV
E\WHVIURPLFPSBVHT WWO WLPH PV
UDGLXVFDPODEMXQLSHUQHWSLQJVWDWLVWLFV
SDFNHWVWUDQVPLWWHGSDFNHWVUHFHLYHGSDFNHWORVV
URXQGWULSPLQDYJPD[VWGGHY PV
>HGLW@
NOTE Notice that in this case, DNS resolution is tested for both an external
host (juniper.net) and an internal one (radius). In order for the internal
resolution to work, then, there should be a DNS server (that is not
shown in Figure 2.2).
Configuring SNMP
SNMP configuration and operation can be complex, but here we’ll
configure the following protocol because you can instruct the SRX to
send notifications (traps) when different events occur, and client
systems can be configured to connect to the SRX to poll for specific
information at any time.
SNMP configuration in the SRX is straightforward, with a general
section specifying device information and community, followed by
more granular sections that specify trap options (which events trigger
notifications), finishing with the client devices that are allowed to poll
the SRX and SNMP servers.
NOTE The “clients” are the management stations in the network that are
allowed to poll the SRX. If you have a dedicated out-of-band network
for management purposes, using a network subnet is very convenient.
For extra security you can also specify individual IP addresses, and
Junos will, in turn, interpret these as /32 or host devices.
2. Set trap options, or the IP that will be the source of the SNMP
updates:
>HGLWVQPS@
URRWVHWWUDSRSWLRQVVRXUFHDGGUHVVOR
Chapter 5: Configuring Network and System Management 49
NOTE Using a loopback interface is a best practice. If you make this a habit
across all devices, then you will have a consistent view of what devices
generated the traps. This makes parsing tasks easier and can simplify
the reporting generated from the network.
3. Configure the SNMP version, port, and which events will generate
updates (use ? to view the different categories available):
>HGLWVQPS@
URRWVHWWUDSJURXSPDQDJHPHQWYHUVLRQY
>HGLWVQPS@
URRWVHWWUDSJURXSPDQDJHPHQWGHVWLQDWLRQSRUW
>HGLWVQPS@
URRWVHWWUDSJURXSPDQDJHPHQWFDWHJRULHVVWDUWXS
>HGLWVQPS@
URRWVHWWUDSJURXSPDQDJHPHQWFDWHJRULHVDXWKHQWLFDWLRQ
>HGLWVQPS@
URRWVHWWUDSJURXSPDQDJHPHQWFDWHJRULHVVHUYLFHV
>HGLWVQPS@
URRWVHWWUDSJURXSPDQDJHPHQWFDWHJRULHVOLQN
VHUYLFHV
`
WDUJHWV^
`
`
Configuring Syslog
System logging has to do with internally generated events, bound to the
control plane of the SRX. NTP, authentication services, chassis events
and many more generate these kinds of events.
NOTE Our focus in this section will be on system logging. Security logging,
when you configure security policies, will be covered in the next
chapter. Security logging refers to the messages generated from match-
ing a security policy, and whether the policy has logging enabled.
These logs refer to events generated at the data plane after processing
user data traffic.
Also, the value DQ\ was used to specify “any facility and severity
value.” For details on specific values, and what they mean, please refer
to the RFC5424: http://tools.ietf.org/search/rfc5424#section-6.2.1. In
the case of Junos, you can simply press [TAB] after keying in the host IP
to see the list of facilities and severities available.
Junos enables logging to files stored in flash memory, but you can mix
this with external logging of any events that you choose, or send all
logging to an external device. This flexibility is great if you need to
send certain events to specific servers.
Even in the factory configuration, Junos provides knobs to reduce the
number and size of the files used for local logging, so you don’t have to
worry about filling up the storage memory. The following example
shows a mix of logging to local files and FTP and authorization events
being logged to different syslog servers:
>HGLWV\VWHPV\VORJ@
URRWVKRZ
DUFKLYHVL]HNILOHV
KRVW^
DXWKRUL]DWLRQZDUQLQJ
`
KRVW^
IWSLQIR
`
ILOHPHVVDJHV^
DQ\FULWLFDO
DXWKRUL]DWLRQLQIR
`
ILOHLQWHUDFWLYHFRPPDQGV^
LQWHUDFWLYHFRPPDQGVHUURU
`
The logs are simple text files, so it is possible to use pattern matching or
other Junos search options to narrow your searches when looking for
something.
Finally, external logs need to be seen at the target server, or via graphi-
cal console, if one is available.
52 Day One: Deploying SRX Series Services Gateways
Chapter 6
About Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Configuring Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Security policies are at the heart of any of the firewall functions of the
SRX Services Gateway platform. By default, traffic entering an inter-
face destined to any address is going to be blocked. This is the expected
default behavior, and no traffic is allowed through the SRX until you
permit it to enter by using security policies.
NOTE An exception to this blocked traffic rule is the traffic in and out of the
fxp0 (management) interface. This interface is an exception because it
resides in the control plane of the device, and it cannot be used for user
data traffic.
About Zones
To review, a zone is a logical container used to group interfaces with
similar security requirements (see Figure 2.1). For example, assume
that in your organization there is a Human Resources department, so
all firewall ports assigned to HR can be bound to the zone “HR.” All
firewall interfaces used by Finance can be bound to a zone “Finance,”
and so on. Zone names are locally significant, and you can name them
anything that makes the most sense to you.
>HGLWVHFXULW\]RQHVVHFXULW\]RQHDGPLQV@
URRWVHWDGGUHVVERRNDGGUHVV3&
Verify the entry and notice how Junos automatically assumes this is a
/32 entry since you didn’t specify a subnet mask:
>HGLWVHFXULW\]RQHVVHFXULW\]RQHDGPLQV@
URRWVKRZ
DGGUHVVERRN^
DGGUHVV3&
`
LQWHUIDFHV^
JH
`
Since the destination address can be any host in the “untrust” zone (the
public web), it actually makes sense in this case to have used any as the
address book for the destination address.
TIP Creating multiple address books for hosts in a zone is not a problem.
However, if you want to gather those individual entries in a group to
simplify your policy creation, then you can create address-sets for this
purpose. The concept is very similar to the creation of an address
58 Day One: Deploying SRX Series Services Gateways
>HGLWVHFXULW\]RQHVVHFXULW\]RQHDGPLQV@
URRWVHWDGGUHVVERRNDGGUHVVVHW3&VDGGUHVV3&
Configuring Services
Services specify the applications that we are matching, a combination
of source/destination ports, protocol, and timeout. The ports and
protocol are part of the TCP/IP packet header, and the timeout refers
to the time that a particular packet will be held in memory before it is
purged, if no subsequent packets match the same security policy.
The SRX Services Gateway devices are stateful firewalls. When an
incoming packet is matched and an action is taken, then an entry
identifying this packet and the corresponding action is held in memory
(session table) so that subsequent packets are processed faster. If, after
a while (the timeout value), no subsequent packets match the same
criteria, the entry is purged from memory. A finite amount of entries
can be held in memory, and that is why the firewall has to be judicious
about what is held there.
You don’t always have to configure services. In fact, there is a list of
pre-defined services, and you can see their details from configuration
mode with the command:
>HGLW@
URRWVKRZJURXSVMXQRVGHIDXOWVDSSOLFDWLRQV
from zone A
Context Lookup to zone B
...
Policy 1
from zone admins
to zone untrust Matching Context
...
ORDERED Matching Policy
CONTEXTS
LOOKUP Specifies Action
Policy default:
deny all
POLICIES
2. Create a policy, giving it a name that makes sense. In this case, you
are asked to create a policy to match any source/destination and
Chapter 6: Writing Basic Security Policies 61
At this time you have already completed the first requirement. This was
a very simplistic example, but you can take additional then actions,
such as enabling counting for accounting purposes, or logging of
events when a session is created, or closed, after matching this policy.
After enabling some of these other options the policy could end up
looking like this:
>HGLWVHFXULW\SROLFLHVIURP]RQHDGPLQVWR]RQHXQWUXVW@
URRWVKRZ
SROLF\DGPLQVBWRBXQWUXVW^
PDWFK^
VRXUFHDGGUHVVDQ\
GHVWLQDWLRQDGGUHVVDQ\
DSSOLFDWLRQDQ\
`
WKHQ^
SHUPLW
ORJ^
VHVVLRQLQLW
VHVVLRQFORVH
`
FRXQW
`
`
Let’s now configure the second requirement from the list at the begin-
ning of this chapter:
Permit custom traffic from any hosts in the zone “admins” to any other
host in the same zone.
>HGLWVHFXULW\SROLFLHV@
URRWHGLWIURP]RQHDGPLQVWR]RQHDGPLQV
>HGLWVHFXULW\SROLFLHVIURP]RQHDGPLQVWR]RQHDGPLQV@
2. Create a policy, giving it a name that makes sense. In this case, you
are asked to create a policy to match custom traffic from any hosts in
the same zone. For the custom traffic you can use the custom
MYSERVICES services-set, configured previously:
>HGLWVHFXULW\SROLFLHVIURP]RQHDGPLQVWR]RQHDGPLQV@
URRWVHWSROLF\LQWUDB]RQHBWUDIILFPDWFKVRXUFHDGGUHVVDQ\GHVWLQDWLRQDGGUHVVDQ\
DSSOLFDWLRQ0<6(59,&(6
>HGLWVHFXULW\SROLFLHVIURP]RQHDGPLQVWR]RQHDGPLQV@
URRWVHWSROLF\LQWUDB]RQHBWUDIILFWKHQORJVHVVLRQLQLW
>HGLWVHFXULW\SROLFLHVIURP]RQHDGPLQVWR]RQHDGPLQV@
URRWVHWSROLF\LQWUDB]RQHBWUDIILFWKHQORJVHVVLRQFORVH
>HGLWVHFXULW\SROLFLHVIURP]RQHDGPLQVWR]RQHDGPLQV@
URRWVHWSROLF\LQWUDB]RQHBWUDIILFWKHQFRXQW
The second policy requirement has been fulfilled. As per the third
requirement, there is no configuration needed, since the default policy
deny-all will activate when the firewall determines the context of the
traffic (from-zone untrust to-zone trust).
Use VKRZ commands to verify the policies configured. Pay close attention to the output. The
GHWDLO option is a favorite since it displays policy statistics.
!VKRZFRQILJXUDWLRQVHFXULW\SROLFLHV
!VKRZVHFXULW\SROLFLHV"
!VKRZVHFXULW\SROLFLHVWR]RQHXQWUXVW
!VKRZVHFXULW\SROLFLHVGHWDLO
Another way to verify that the security policies are working as expect-
ed is to test data traffic. In a production network, you can also inspect
the session table that the SRX creates and match for specific informa-
tion.
After logging into the PC at the “admins” zone and initiating multiple
traffic sessions, inspect what the SRX is keeping in the session table
with VKRZ commands:
>HGLWVHFXULW\SROLFLHV@
URRWUXQVKRZVHFXULW\IORZVHVVLRQ
6HVVLRQ,'3ROLF\QDPHDGPLQVBWRBXQWUXVW7LPHRXW
,Q!WFS,IJH
2XW!WFS,IJH
6HVVLRQ,'3ROLF\QDPHDGPLQVBWRBXQWUXVW7LPHRXW
,Q!WFS,IJH
2XW!WFS,IJH
6HVVLRQ,'3ROLF\QDPHDGPLQVBWRBXQWUXVW7LPHRXW
,Q!WFS,IJH
2XW!WFS,IJH
6HVVLRQ,'3ROLF\QDPHDGPLQVBWRBXQWUXVW7LPHRXW
,Q!XGS,IJH
2XW!XGS,IJH
VQLS!
Every new packet that matches the criteria of a policy with an action of
permit will generate an entry in this table. You can confirm the source/
destination IPs, ports, protocol, time-out values, interfaces involved,
the policy that matched the traffic, and more. Notice that entries are
grouped in three lines at the time, representing the bidirectional
information of a session (a flow). As traffic traverses, the SRX creates
bidirectional entries in memory to allow the return traffic back through
(this is what is meant by stateful behavior).
64 Day One: Deploying SRX Series Services Gateways
SRXs are capable of so much logging, that they can quickly overwhelm
the routing engine if security logging is attempted via the control plane
(out the fxp0 interface).
To overcome this important aspect of logging security events, an
administrator can dedicate a revenue port for logging tasks. Doing so
will cause logging for security events to be sent out the SRX from the
data plane, rather than the control plane, resembling the behavior of the
branch SRX devices that don’t have a dedicated hardware control
plane.
The logging parameters configured in the security policies are un-
changed regardless of the way you do the logging, providing you learn
how to configure using these three methodologies:
Logging via a revenue port (applicable to SRX branch and high-
end).
Logging via the control plane (applicable to SRX high-end).
Logging to a NSM server (applicable to SRX branch and high-end).
>HGLW@
URRWVHWVHFXULW\ORJPRGHVWUHDP
>HGLW@
URRWVHWVHFXULW\ORJIRUPDWVGV\VORJ
>HGLW@
URRWVHWVHFXULW\ORJVWUHDP6<6/2*B6(59(5KRVW
NOTE Other options, such as the destination port, can be configured in case
you are not using the default (UDP port 1514). Also note that the host
192.168.2.2, does not have any syslog services, but it is being config-
ured here for example purposes.
66 Day One: Deploying SRX Series Services Gateways
2. Configure the source of messages and the syslog server. Once again,
a name is required for the server, but it is locally significant and you are
encouraged to use something meaningful to facilitate its identification
when troubleshooting or auditing the firewall config:
>HGLW@
URRWVHWVHFXULW\ORJVRXUFHDGGUHVV
>HGLW@
URRWVHWVHFXULW\ORJVWUHDP6<6/2*B6(59(5KRVW
3. Configure logging via the control plane, so any logs generated in the
data plane as a consequence of a security policy match, are sent to the
control plane:
>HGLW@
URRWVHWVHFXULW\ORJPRGHHYHQW
NOTE By default, SRX devices do not send native syslog messages to NSM,
only the logs stored in two files in the SRX. If logging is from a high-
end SRX, then security logs must be sent to the control plane first.
1. Configure the logging mode and format. Options available for the
format are V\VORJ (standard) and VGV\VORJ (structured):
>HGLW@
URRWVHWVHFXULW\ORJPRGHHYHQW
>HGLW@
URRWVHWVHFXULW\ORJIRUPDWVGV\VORJ
Chapter 6: Writing Basic Security Policies 67
2. Configure the source of traffic and NSM as the target syslog server.
A name is required for the target, but it is locally significant, and you
are encouraged to use something to facilitate its identification when
troubleshooting or auditing the firewall config:
>HGLW@
URRWVHWVHFXULW\ORJVRXUFHDGGUHVV
>HGLW@
URRWVHWVHFXULW\ORJVWUHDP6<6/2*B6(59(5KRVW
3. Configure logging via the control plane and rate limit the entries
(this step is only required for high-end SRX, so omit if you are
configuring a branch device):
>HGLW@
URRWVHWVHFXULW\ORJPRGHHYHQWHYHQWUDWH
>HGLW@
URRWVHWV\VWHPV\VORJILOHGHIDXOWORJPHVVDJHVDQ\DQ\
That’s it. You should have your first security policies running and a
method to log them. Let’s move on now to learning how to prepare
those packets that are leaving the policy in route for their destinations.
68 Day One: Deploying SRX Series Services Gateways
Chapter 7
NAT Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
VQLS!
The output indicates that there is an incoming packet with a source IP
address of 192.168.2.2, destined to 209.239.112.126. The return
traffic shows a packet being sourced from 209.239.112.126, destined
to the exact IP address that originated the transaction, 192.168.2.2.
When the source and destination IP addresses remain unchanged, as
in this example, it is indicative that the traffic was routed as opposed
to translated (NATed).
NAT Types
The SRX is capable of performing different forms of translation of the
source and destination headers. The options are: source, destination,
and static.
This chapter shows you how to configure source NAT to translate the
source IP of incoming packets as they leave the SRX. There are several
options available when executing this kind of translation. For exam-
ple, you can configure it so that the source IP is translated to the IP of
the egress interface, you can use a different pool of IP addresses and
no port address translation, and there are also a few more options.
Figure 7.1 illustrates an example of source NAT. Aside from translat-
ing the source IP to that of the interface ge-0/0/2, the SRX also
translates the source port (performs port address translation or PAT
by default). Translating the source IP allows sharing a single IP
address between thousands of hosts, while translating the source port
gives the SRX the possibility of tracking who initiated a particular
flow, and the ability to hand off the return traffic to the corresponding
host that opened the connection.
Chapter 7: Configuring NAT Source 71
2. Define the context of the traffic. Where is it coming from and where
is going to?
>HGLWVHFXULW\QDWVRXUFHUXOHVHWLQWHUQHWBQDW@
URRWVHWIURP]RQHDGPLQV
>HGLWVHFXULW\QDWVRXUFHUXOHVHWLQWHUQHWBQDW@
URRWVHWWR]RQHXQWUXVW
3. Now that you have created a rule-set, and defined the context of the
traffic, configure an actual rule that matches all the incoming traffic
from the “admins” subnet going to any location, and NAT source that
using the egress interface. Again, choose a name for the rule that is
meaningful to you:
>HGLWVHFXULW\QDWVRXUFHUXOHVHWLQWHUQHWBQDW@
URRWHGLWUXOHDGPLQVBDFFHVV
>HGLWVHFXULW\QDWVRXUFHUXOHVHWLQWHUQHWBQDWUXOHDGPLQVBDFFHVV@
URRWVHWPDWFKVRXUFHDGGUHVV
>HGLWVHFXULW\QDWVRXUFHUXOHVHWLQWHUQHWBQDWUXOHDGPLQVBDFFHVV@
URRWVHWPDWFKGHVWLQDWLRQDGGUHVVDOO
>HGLWVHFXULW\QDWVRXUFHUXOHVHWLQWHUQHWBQDWUXOHDGPLQVBDFFHVV@
URRWVHWWKHQVRXUFHQDWLQWHUIDFH
>HGLWVHFXULW\QDWVRXUFHUXOHVHWLQWHUQHWBQDWUXOHDGPLQVBDFFHVV@
URRWFRPPLW
FRPPLWFRPSOHWH
74 Day One: Deploying SRX Series Services Gateways
6HVVLRQ,'3ROLF\QDPHDGPLQVBWRBXQWUXVW7LPHRXW
,Q!WFS,IJH
2XW!WFS,IJH
6HVVLRQ,'3ROLF\QDPHDGPLQVBWRBXQWUXVW7LPHRXW
,Q!XGS,IJH
2XW!XGS,IJH
6HVVLRQ,'3ROLF\QDPHDGPLQVBWRBXQWUXVW7LPHRXW
,Q!XGS,IJH
2XW!XGS,IJH
VQLS!
Notice the “Out” line for every session – the responses are being
directed to the IP address 66.129.250.1. This IP address corresponds
to the SRX egress interface, confirming the proper operation of source
NAT.
Chapter 7: Configuring NAT Source 75
>HGLWVHFXULW\QDWVRXUFHUXOHVHWLQWHUQHWBQDWUXOHDGPLQVBDFFHVV@
URRWVHWWKHQVRXUFHQDWSRROSXEOLFB1$7BUDQJH
>HGLWVHFXULW\QDWVRXUFHUXOHVHWLQWHUQHWBQDW@
URRWHGLWUXOH12BWUDQVODWH
2. Define the match criteria (what you are going to except from
translation):
>HGLWVHFXULW\QDWVRXUFHUXOHVHWLQWHUQHWBQDWUXOH12BWUDQVODWH@
URRWVHWPDWFKVRXUFHDGGUHVV
>HGLWVHFXULW\QDWVRXUFHUXOHVHWLQWHUQHWBQDWUXOH12BWUDQVODWH@
URRWVHWPDWFKGHVWLQDWLRQDGGUHVVDOO
3. Configure the action when that particular source/destination is
identified:
>HGLWVHFXULW\QDWVRXUFHUXOHVHWLQWHUQHWBQDWUXOH12BWUDQVODWH@
URRWVHWWKHQVRXUFHQDWRII
>HGLWVHFXULW\QDWVRXUFHUXOHVHWLQWHUQHWBQDW@
URRWLQVHUWUXOH12BWUDQVODWHEHIRUHUXOHDGPLQVBDFFHVV
IMPORTANT This step is crucial, and if you forget about it or ignore it, then the host
192.168.2.2 will continue to be translated. Remember that rules in
NAT rule-sets are evaluated in a top-down fashion like a security
policy, so there is always a need to analyze and reorganize the rules
when necessary.
There. We’ve accomplished our three items for NAT. Our SRX is
properly analyzing and sending traffic according to our network
topology as shown way back in Chapter 2.
After completing the initial configuration you can continue the
configuration of more services supported by the SRX. Some of these
services are: IPS, IPSec, UTM, high-availability, and more advanced
routing configurations. The online documentation available provides
a lot of details on how to configure every service, and this documenta-
tion gets updated with every new Junos release. Look for it here:
http://www.juniper.net/techpubs/hardware/junos-srx/index.html.
78 Day One: Deploying SRX Series Services Gateways
More Day One books are also being developed, especially for the SRX
platform of services gateway. Keep checking the website for new
additions at www.juniper.net/daysone.
And finally, if you need more help, get the Junos Security book from
O’Reilly publishers. Look for it here: www.juniper.net/books.
Now let’s apply what we’ve done to multiple SRX devices as efficiently
as possible.
Chapter 8
If you are installing and managing multiple SRX devices and other
Juniper hardware, the Network and Security Manager (NSM) will
help you keep a more consistent view of the network, and will simplify
your configuration and troubleshooting tasks. In this chapter you’ll
learn how to import your SRX into NSM. The installation and con-
figuration of NSM, and the devices already imported, are out of the
scope of this book. The intention here is to jump start NSM usage by
connecting your SRX and NSM, and to ensure that the SRX is prop-
erly imported so that you can continue managing it via NSM.
>HGLW@
URRWFRPPLW
FRPPLWFRPSOHWH
Chapter 8: Importing the SRX into NSM 81
3. Specify that the device is reachable and fill in the IP address and
administrator account fields. The IP address in this example is that of
the fxp0 interface, and the administrator account is from the SRX, not
the NSM.
From this moment on, you can continue managing the SRX via NSM.
Any changes done to the SRX via J-Web, or the CLI, are overwritten
by NSM in the next configuration update, unless you import the device
configuration first.
86 Day One: Deploying SRX Series Services Gateways
Chapter 9
Troubleshooting Tools
Enabling Traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
88 Day One: Deploying SRX Series Services Gateways
Flow
Input Input Output Output
Policer services Shaper
queue filter filter queue
module
Route
lookup
Now examine what is done inside the flow services module represented
in Figure 9.2. Screens, NAT, ALG, and IPSec, are only some of the
services performed by this module. Figure 9.1 and 9.2 are explained in
great detail in the Junos Security Configuration Guide found here (for
version 10.1): https://www.juniper.net/techpubs/software/junos-srx/
junos-srx10.1/index.html.
Chapter 9: Troubleshooting Tools 89
First Path
Match Services
Yes Screens TCP NAT
session? ALG
Fast Path
Flow module
Per-packet filters
As you spend more time in the SRX and uncover its capabilities for
more advanced services, you will realize how important it is to know
this information. So when time permits, spend a few minutes in the
aforementioned guide reading the more detailed explanations of how
the packets are processed – it is time well invested if you want to
become proficient with administering SRX devices.
Additionally, it’s important to mention that branch SRX devices are
capable of bypassing the flow services module for selected configura-
tions. This is called packet-based mode processing (as opposed to
flow-based processing). The extra flexibility of these platforms makes
it a little more difficult to fully understand the packet processing
through the SRX.
You can log events of many different kinds, as shown throughout this
chapter, however, you will also find log files that were not configured
by you or that exist by default. One such log file is messages, used by
the system to log kernel and services messages.
To look for failed password attempts from admins attempting to
connect via SSH, you can try the following combination:
!VKRZORJPHVVDJHV_PDWFKVVK_PDWFK´)DLOHGSDVVZRUGµ_WULP
This command would look in the PHVVDJHV log file, and match for sshd
events where “Failed password” attempts were recorded. The “trim
38” simply omits the first 38 characters from the output if you are not
interested in the time stamps.
Another outstanding option when dealing with logs is to use the VWDUW
PRQLWRU command, which allows you to monitor a log file in real time,
so when an event happens it is displayed in console right away. Here is
an example where you look for failed ssh attempts in real time.
PHVVDJHV
-XQ65;VVKG>@)DLOHGSDVVZRUGIRUMRKQIURPSRUW
VVK
EDUQ\V#65;!
PRQLWRUDQGV\VORJRXWSXWGLVDEOHGSUHVV(6&4WRHQDEOH
3. Stop the real time monitoring of the file. This does not cause
logging to stop recording events, but the events are not shown on the
console anymore:
EDUQ\V#65;!PRQLWRUVWRS
Chapter 9: Troubleshooting Tools 91
Examining the system status can be done with show commands. You have used several show
commands if you’ve been following the examples in this book, but many more options are also
available to find out chassis and event status information. Try these on your console right now.
To check system uptime:
!VKRZV\VWHPXSWLPH
There are many parameters available to check chassis related information, so check the help
prompt to see them all:
!VKRZFKDVVLV"
MORE? The complete list of available show commands and their descriptions
can be found in the CLI Reference Guide, found here (for version 10.1)
at www.juniper.net/techpubs/software/junos-srx/junos-srx10.1/index.
html. You can also find lots of device agnostic command usage exam-
ples in Day One books from the Junos Fundamentals Series: www.
juniper.net/dayone.
Enabling Traceoptions
Traceoptions are the equivalent of debugging tools from other vendors’
products, so if you are coming from a background of using Juniper
Networks ScreenOS firewalls and are familiar with GHEXJIORZEDVLF,
then this section will show you how to do the same in the SRX.
To debug packets as they traverse the SRX, you need to configure
traceoptions and flag basic-datapath. This will trace packets as they
enter the SRX until they exit, giving you details of the different actions
the SRX is taking along the way.
92 Day One: Deploying SRX Series Services Gateways
NOTE Steps 2 and 3 are necessary because Junos only captures one direc-
tional flows. Multiple packet-filters then let you capture both the
outgoing and reverse flows. Individual packet-filter configurations like
in this example are processed as OR statements, instructing the SRX
to match traffic that matches one filter or the other.
`
`
V\VORJ^
DUFKLYHVL]HNILOHV
XVHU
^
DQ\HPHUJHQF\
`
ILOHPHVVDJHV^
DQ\FULWLFDO
DXWKRUL]DWLRQLQIR
`
ILOHLQWHUDFWLYHFRPPDQGV^
LQWHUDFWLYHFRPPDQGVHUURU
`
`
PD[FRQILJXUDWLRQVRQIODVK
PD[FRQILJXUDWLRQUROOEDFNV
OLFHQVH^
DXWRXSGDWH^
XUOKWWSVDHMXQLSHUQHWMXQRVNH\BUHWULHYDO
`
`
:DUQLQJPLVVLQJPDQGDWRU\VWDWHPHQWV¶URRW
DXWKHQWLFDWLRQ·
`
LQWHUIDFHV^
LQWHUIDFHUDQJHLQWHUIDFHVWUXVW^
PHPEHUJH
PHPEHUIH
PHPEHUIH
PHPEHUIH
PHPEHUIH
PHPEHUIH
PHPEHUIH
XQLW^
IDPLO\HWKHUQHWVZLWFKLQJ^
YODQ^
PHPEHUVYODQWUXVW
`
`
`
`
JH^
XQLW
`
YODQ^
XQLW^
IDPLO\LQHW^
DGGUHVV
`
`
96 Day One: Deploying SRX Series Services Gateways
`
`
VHFXULW\^
QDW^
VRXUFH^
UXOHVHWWUXVWWRXQWUXVW^
IURP]RQHWUXVW
WR]RQHXQWUXVW
UXOHVRXUFHQDWUXOH^
PDWFK^
VRXUFHDGGUHVV
`
WKHQ^
VRXUFHQDW^
LQWHUIDFH
`
`
`
`
`
`
VFUHHQ^
LGVRSWLRQXQWUXVWVFUHHQ^
LFPS^
SLQJGHDWK
`
LS^
VRXUFHURXWHRSWLRQ
WHDUGURS
`
WFS^
V\QIORRG^
DODUPWKUHVKROG
DWWDFNWKUHVKROG
VRXUFHWKUHVKROG
GHVWLQDWLRQWKUHVKROG
WLPHRXW
`
ODQG
`
`
`
]RQHV^
VHFXULW\]RQHWUXVW^
KRVWLQERXQGWUDIILF^
V\VWHPVHUYLFHV^
DOO
`
SURWRFROV^
DOO
`
Appendix 97
`
LQWHUIDFHV^
YODQ
`
`
VHFXULW\]RQHXQWUXVW^
VFUHHQXQWUXVWVFUHHQ
LQWHUIDFHV^
JH^
KRVWLQERXQGWUDIILF^
V\VWHPVHUYLFHV^
GKFS
WIWS
`
`
`
`
`
`
SROLFLHV^
IURP]RQHWUXVWWR]RQHXQWUXVW^
SROLF\WUXVWWRXQWUXVW^
PDWFK^
VRXUFHDGGUHVVDQ\
GHVWLQDWLRQDGGUHVVDQ\
DSSOLFDWLRQDQ\
`
WKHQ^
SHUPLW
`
`
`
`
`
ZODQ^
FOXVWHUYODQGHIDXOW^
QDPHMXQLSHUDSFOXVWHU
GHIDXOWFOXVWHU
LQWHUIDFHV^
YODQ
`
`
`
YODQV^
YODQWUXVW^
YODQLG
OLQWHUIDFHYODQ
`
`
98 Day One: Deploying SRX Series Services Gateways
To Apply a License:
1. Connect to your device and check the status of your license:
URRW!VKRZV\VWHPOLFHQVH
/LFHQVHXVDJHQRQH
/LFHQVHVLQVWDOOHGQRQH
2. The output in this case indicates that there are no features config-
ured that require licensing. An example would be if IPS services were
configured.
Double-check that the license received matches your chassis’s serial
number. To view the serial number:
URRW!VKRZFKDVVLVKDUGZDUH
+DUGZDUHLQYHQWRU\
,WHP9HUVLRQ3DUWQXPEHU6HULDOQXPEHU
'HVFULSWLRQ
&KDVVLV$$$'65;
«
3. Open the license file received in notepad or any other text editor.
Copy all of its contents to the clipboard by highlighting everything,
and then clicking Edit->Copy.
4. On the SRX, type the following operational mode command, and
copy the contents of the clipboard, followed by Ctrl-D (escape
sequence):
URRW!UHTXHVWV\VWHPOLFHQVHDGGWHUPLQDO
>7\SHA'DWDQHZOLQHWRHQGLQSXW
HQWHUEODQNOLQHEHWZHHQHDFKOLFHQVHNH\@
-8126DHDTHDTPLIDWLQMTKEDXLPETJH]TTETFGZ[
OR[YDXHIINR[ZZKNPITVR\JW]QMN
XSFIIE[UYNWXWXZMRFQJ[SHYE]
SVT
-8126VXFFHVVIXOO\DGGHG
DGGOLFHQVHFRPSOHWHQRHUURUV
URRW!
URRW!VKRZV\VWHPOLFHQVH
/LFHQVHXVDJH
/LFHQVHV/LFHQVHV/LFHQVHV([SLU\
)HDWXUHQDPHXVHGLQVWDOOHGQHHGHG
LGSVLJ87&
/LFHQVHVLQVWDOOHG
/LFHQVHLGHQWLILHU-8126
/LFHQVHYHUVLRQ
9DOLGIRUGHYLFH$$$'
)HDWXUHV
LGSVLJ,'36LJQDWXUH
GDWHEDVHG87&87&
URRW!
2. Add the NAS client, in this case the SRX. Ensure that the share
secret matches to the one configured in the firewall. The make and
model selected works fine, as the authentication mechanism works the
same in M/T Series of routers.
102 Day One: Deploying SRX Series Services Gateways
3. Add users, such as our book’s testbed users,: barnys, carrie, halle
and max. Notice their names \\CAMLAB\[user] indicates that this can
part of the CAMLAB domain. Also, when there is a request from the
SRX it asks the SBR server to check for the User-Password against the
submitted username.
3. The next two screenshots present the same process for the
CONSULTANT group. Notice that the return list is more specific,
allowing configuration changes only over interfaces.
Appendix 105
4. The next screenshot is the same process for the READ-ONLY and
OPERATOR groups. Again, take note of the permissions for each
group.
106 Day One: Deploying SRX Series Services Gateways
6. Make sure that you have the groups created in Active Directory, and
that the users belong to their corresponding groups, according to the
original intentions.
107
www.juniper.net/dayone