Tuesday, 30 October 2012

System Services - NTP

NTP (Network Time Protocol) is a client/server protocol used to sync time information between a NTP server and a client. The protocol is also hierarchical with levels of the hierarchy defined as 'Stratums'. The top of the hierarchy 'Stratum 0' contains reference clocks. These clocks are highly accurate and could be atomic or GPS. Stratum 1 would reference Stratum 0 and so on.



NTP Configuration & Validation
The same basic lab setup was used for this exercise.

The screenshots below outline the configuration. The timezone is set along with two NTP servers. The command 'boot-server' can specify a server for use when the device boots or becomes a passive member in a chassis cluster.

This is how the config looks.

The command 'show ntp status' can be used to confirm NTP is running and time is properly synced.


NTP Server Configuration
Once the SRX is configured with an NTP client (where it can source time from) it can also function as a NTP server to other clients on the network. There is not additional configuration needed other than allowing the NTP protocol in the host-inbound-traffic configuration.


NTP Server Configuration
NTP communication can be authenticated using MD5. First a NTP key must be created, then the key can be used when configuring a server, and lastly a trusted-key can be specified so that clients wanting to sync NTP with the SRX (SRX as a NTP server) will only use authenticated requests. See the screenshot below for command details.




Monday, 29 October 2012

System Services - DNS

DNS (domain name system) is a hierarchical and distributed system that provides a method to map names into IP addresses. The naming structure looks like domain3.domain2.domain1. Each domain or level of the hierarchy is a zone. Each zone has authoritative DNS Servers which are servers that hold the DNS records for that zone.

DNS Name Breakdown
For example we can break down the DNS address "www.google.com." The following zones exist in this name. We will use a handy tool called NSLookup to find the authoritative servers for each zone. Here is a link to a good web page on NSlookup.

[.] Technically the "." at the end of 'www.google.com.' is the root of the DNS hierarchy. It is implied and is usually appended automatically which is why it is not mandatory to enter a period after the URL.


[com]  is the next zone, below are the authoritative servers. The authoritative name servers here would have a record for google.com.

[google] is the next zone, below are the authoritative servers. The authoritative name servers here would have a record for www.google.com.

[www] is the last zone (technically the last zone is an entity which we want an IP address for). Below the first command is looking up the authoritative name servers for the zone www.google.com. This command requests the IP address of www.google.com.

DNS Lookup Process
The lookup structure we went through above would be called a 'Iterative' lookup. In this type of lookup the first query is done at the root level and individual queries are done as you move up the hierarchy. This lookup is commonly done by DNS servers. The second type of lookup is 'recursive', in this type of lookup a single query is made for 'www.google.com' and a downstream DNS server responds. This downstream DNS server may have the results cached or it may complete an iterative lookup to find the IP address.

Basic DNS Configuration
The diagram below outlines the basic lab topology used to work through this exercise. A Windows 2008 server represents an internal domain server which is authoritative for our domain 'testdns'.


SRX Configuration
The screenshots below outline the configuration steps. The lab domain 'dnstest' is used, and the DNS server IP address is 192.168.1.110.


Results
The CLI output below demonstrates that the SRX successfully resolved the name 'nas'.
The packet captures below display the DNS request and response. Note that the SRX appended 'dnstest' behind the name 'nas'. This is because we have configured the domain-name in the SRX device.


The CLI output and packet captures below demonstrates that the SRX successfully resolved the name 'www.google.com'



Conclusion
This blog post reviewed DNS and basic configuration so that the SRX device could resolve host names. The use case where the SRX would resolve an address on behalf of a client (DNS Proxy) does not seem to be supported. The only information I could find is this knowledge base article [Does Junos Support DNS-Proxy?] outlining that the feature was removed for security reasons. I would like to know if this feature is going to be re-introduced. I can see many use cases where this feature could be used. Anyone have any information on this?

Friday, 26 October 2012

System Services - DHCP

DHCP (Dynamic Host Configuration Protocol) is a client / server protocol used to automatically assign an IP address to a node on the network. The following basic breakdown outlines the messages that take place when a host acquires an IP address using DHCP.
  • Discover - In this message the client broadcasts a request using UDP port 67. Some options or attributes can be included in the address such as requesting to have the same address the client might have had before. 
  • Offer - In this message a DHCP server responds to the client on UDP port 68. This message includes the IP address and lease information the server is offering the client.
  • Request - In this message the client responds to the server to confirm the offer. The client may receive many offers from multiple DHCP servers. It will only choose and respond to one offer.
  • Acknowledgement - In this message the server confirms to the client that the IP address has been allocated to the client.
The Juniper SRX can be configured as a DHCP server, DHCP client or both.

DHCP Client Configuration & Validation
In this exercise the public interface of the SRX100 will be configured as a DHCP client. This will allow the SRX to acquire a public IP address from the ISP. The following diagram outlines the basic topology.

The following command configures interface fe-0/0/0 on the SRX100 acquire an IP address via DHCP. The first command enables DHCP on the interface fe-0/0/0 and the second command sets DHCP as an inbound service.
set interfaces fe-0/0/0 unit 0 family inet dhcp
set security zones security-zone INTERNET interfaces fe-0/0/0.0 host-inbound-traffic system-services dhcp 

The following command can be used to verify DHCP client operation.



DHCP Server Configuration & Validation
In this exercise the SRX100 will be configured as a DHCP server for the internal network of 192.168.1.0/24. The following diagram outlines the basic topology.




The following commands configure the SRX100 to function as a DHCP server. The first command sets the range of addresses that can be handed out to clients. The three commands set parameters that can be passed to the client, in this case they are DNS and a default gateway. Other parameters such as WINS, domain name or vendor specific options can also be specified. The last command allows DHCP as an inbound service on the LAN interface of the SRX.

set system services dhcp pool 192.168.1.0/24 address-range low 192.168.1.100 high 192.168.1.150
set system services dhcp pool 192.168.1.0/24 name-server 8.8.8.8
set system services dhcp pool 192.168.1.0/24 name-server 8.8.4.4
set system services dhcp pool 192.168.1.0/24 router 192.168.1.1
set security zones security-zone TRUST interfaces vlan.192 host-inbound-traffic system-services dhcp 

The following commands can be used to verify DHCP server operation.
show system services dhcp pool - This command outlines the DHCP pools configured with the ranges included.
show system services dhcp binding - This command outlines the current addresses that are assigned to clients including the lease times.
show system services dhcp statistics - This command outlines some counters and stats for DHCP.
show system services dhcp conflicts  - This command outlines conflicts such as duplicate IP use.

The screenshot below outlines these commands.


DHCP Relay Configuration & Validation
DHCP is broadcast based, if the client and server are on different networks the DHCP server will not see the requests from the client. In this exercise the SRX100 will be configured to relay DHCP requests to an external DHCP server. The following diagram outlines the basic topology.

The following commands configure the SRX100 to function as a DHCP relay agent.

set forwarding-options helpers bootp description "DHCP Relay"
set forwarding-options helpers bootp server 192.168.2.100
set forwarding-options helpers bootp interface vlan.192
set security zones security-zone TRUST interfaces vlan.192 host-inbound-traffic system-services dhcp
set security zones security-zone TRUST interfaces vlan.193 host-inbound-traffic system-services dhcp


The following commands can be used to verify DHCP relay operation.


Thursday, 25 October 2012

System Services - SNMP

SNMP (Simple Network Management Protocol) is a client/server protocol used for querying and setting parameters or objects on a device. Versions 1, 2c and 3 exist for this protocol. SNMPv1 and SNMPv2c are similar, the main difference being that some extensions were added into v2c. SNMPv3 provides additional features to provide security to the protocol. SNMPv1 and v2c are criticized from a security perspective as the passwords and data are passed in clear-text format. The term managers and agents is used to describe the entities involved in SNMP (there are exceptions to these terms in SNMPv3, but we won't worry about these). A manager could be something like a NMS (Network management station) and a agent could be a device such as a Juniper SRX device.

MIB (Management Information Base)
Objects that could be polled or configured by a manager are organized in a MIB (Management Information Base). The MIB is organized in a hierarchical fashion with objects at the end of the tree. Objects are mapped or named using OID (Object Identifiers) which are displayed in a dotted integer format. The integers map the parameter from the top level of the hierarchy through the tree. For example 1.3.6.1.2.2.1 would be the system objects under the MIB-II category. See the picture below for a graphical view (keep in mind that this is only showing a portion of the entire MIB tree).

MIB-II & Private MIBs
The OIDs under the MIB-II branch are defined by the SNMP standard. Common objects such as "sysName" or "sysContact" are located here. The webpage oid-info.com/get/1.3.6.1.2.1 is a great place to browse the avaliable objects under the MIB-II category. As mentioned above, private OIDs can be used by vendors. The OID used by vendors for private use is 1.3.6.1.4 (as you can see in the image above). The OID 1.3.6.1.4.1.2636 1.3.6.1.4.1.2636 is specifically used by Juniper Networks. The webpage Juniper Networks Enterprise-Specific-MIBs outlines the various objects Juniper has created for their products.

SNMP Messages
SNMP uses specific types of messages to send and receive information. The three main messages are 'GET', 'SET' and 'TRAP' (there are additional messages such as GETNEXT, however this detail isn't necessary for this post.)

GET: Is a message type where a manager would send a request to the agent. The OID would be used to specify which object the manager wished to query.
SET: Is a message type where a manager would set or modify an object on the agent. Again, the OID would be used to specify which object the managed wished to set/modify.
TRAP: Is a message type where the agent alerts the manager of an event.

SNMP Versions
In SNMPv1 the concept of communities is used. These communities can be thought of as passwords. The protocol supports a two communities one for 'read' and another for 'read&write' permissions. SNMPv2c uses the same community and message structure as SNMPv1 with the addition of more message types.

I find the explanation of SNMPv3 to be confusing but at the simplified level SNMPv3 maintains all of the same message types as SNMPv1/v2c with the addition of security.

SNMPv2c Configuration 
The same basic lab topology will be used for these exercises.

The image below outlines the basic SRX SNMP configuration. Standard parameters such as 'name' and 'location' are set. The SNMP read and read/write communities (passwords) are defined. Also we have used the 'clients' option under the read/write community to only accept SNMP requests from the specified host of 192.168.1.108. Alternatively we could use a firewall filter on an interface to accomplish this as well. Lastly we need to allow the SNMP protocol under host-inbound-traffic.

Below is how the configuration appears.

Using the resrouces listed above we know that 1.3.6.1.4.1.2636 is the Juniper private MIB. The command 'show snmp mib walk' can be used to display all of the OIDs.

This command can also be used to display the SNMP MIB-II defined OIDs.

To test the configuration we will use Net-SNMP and will use the sysContact object under MIB-II for demonstration.

The wireshark captures below outline the SNMP request that was made for the sysContact OID.



SNMPv3 Configuration
The following commands were used to configure SNMPv3 on the SRX100:

set snmp v3 usm local-engine user v3user authentication-md5 authentication-password simplepass
set snmp v3 usm local-engine user v3user privacy-des privacy-password simplepass
set snmp v3 vacm security-to-group security-model usm security-name v3user group v3group
set snmp v3 vacm access group v3group default-context-prefix security-model any security-level privacy read-view snmpview1
set snmp v3 vacm access group v3group default-context-prefix security-model any security-level privacy write-view snmpview1
set snmp v3 vacm access group v3group default-context-prefix security-model any security-level privacy notify-view snmpview1
set snmp view snmpview1 oid 1.*

The first two commands configure a user 'v3user' and assign authentication and encryption settings with passwords. The next commands configure a security group and adds the user 'v3user' to this group. The next three commands configure parameters of the security group. The privacy statement ensures that authentication and encryption are used for this security group. Also the access this security group has is defined by the view of 'snmpview1'. We used a wildcard in snmpview1 to allow any OID, you could apply a detailed policy here to allow/deny certain OIDs. The following diagram helps to outline a simplified description of SNMPv3 configuration.
Below is a screenshot of the configuration.

To test the configuration we will use the same sysContact object under MIB-II as we demonstrated with the previous exercise.

The following wireshark capture outlines the SNMPv3 request. Notice that the PDU messages are now encrypted.


Wednesday, 24 October 2012

System Services

System Services is another topic listed on the JNCIE-SEC exam blueprint. To cover this topic I will be writing posts for the following sub-topics:

  • SNMP
  • DHCP
  • DNS
  • NTP
  • Telnet, SSH and J-Web (Management Services)

If anyone has suggestions to better review the System Services topic please feel free to leave comments. 

Tuesday, 23 October 2012

User Account Configuration Example - RADIUS Attributes

This blog post will be a continuation of the previous post "User Account Configuration Example - RADIUS Basic" please feel free to reference the material in the previous post. In the exercises below I will take a step further and utilize RADIUS attributes. The lab topology will be the same as the previous post. I utilized VMware Workstation to create an instance of Windows Server 2008 R2 (for the radius configuration), and used an SRX100 for the device configuration.
RADIUS Attributes
RADIUS attributes are used to carry specific data between the client and server. There are a number of attribute types listed in the standard and more than one attribute can be in a single RADIUS message. Specifically we will focus on attribute type 26 which is defined as Vendor-Specific. Attributes can be used to pass information from the RADIUS server to the client (SRX device). Here is a link of the RADIUS Attributes supported in Junos 11.1 for user authentication.


Example#1 - Using RADIUS Attributes to Specify a different User Template
In the previous exercise we set up a RADIUS server to authenticate our test user 'Fred'. The default user template of 'remote' is used to provide read-only access. In this exercise we will to use a different (non-default) user template to provide a different level of access.

To demonstrate this a new user 'Barney' will be created. On the SRX a new user template called 'remote-template-2' will be created with super-user permissions. The RADIUS server will be configured to pass the user template to Junos when 'Barney' logs in. Many templates can be used to provide a wide variety of access policies using RADIUS.

Configuration - Windows Server 2008 R2
1. Create a new user 'barney' (refer to the previous blog post for screenshot examples). Similar to the previous post we will use simple users and user groups within Windows Server 2008.

2. Create a new group 'superusers' (refer to the previous blog post for screenshot examples).

3. Create a new Network Policy on the NPS Server control panel.

4. In this section name the policy, I have used the name 'Junos Superusers' for this policy name. Leave the type as 'Unspecified'.

5. Set the conditions to grant access based on user groups. In this case the user group 'superusers' is used as Barney (our test user) is a member of this group.

6. Make sure to enable PAP under constraints, all other settings can be left at default. Remember PAP passes user information in clear-text so considerations should be made before deploying PAP in a production network.

7. Ensure the only standard attribute is 'Service Type = Login' as outlined below.

8. In this step we configure the vendor specific RADIUS attribute. Essentially we are going to use the 'Juniper-Local-User-Name' attribute to apply a user template to users authenticated with this policy. The screenshots below outlines the configuration.



Configuration - SRX100
The configuration below outlines the command to create a new user template. In this example the name 'remote-template-2' is used and a class of 'super-user' is applied to this template.

Here is what the config looks like.


Testing
Now that configuration is complete we can test the login. As you can see below the login is successful. We also confirmed that this user can access the configuration menu.

Below is a packet capture screenshot of the RADIUS traffic that took place to authenticate Barney. In the access-request you can see the username is identified. In the reply the radius code is 'access-accept' showing the user was authenticated Additionally the 'Juniper-Local-User-Name' attribute is passed in the access-accept reply assigning Barney to the class configured under remote-template-2 which is super-user.




Example#2 - Using RADIUS Attributes to Apply Allow/Deny Commands to Users 
In this exercise we will demonstrate how allow/deny commands and configuration can be passed to the Junos device using RADIUS attributes. Currently the user 'Barney' has super-user access, once logged in he could run the command 'request system reboot' to reset the Junos device. We could use the deny-commands RADIUS attribute to limit this command so Barney could not reboot the device while still having access to all other commands. Keep in mind no configuration is needed on the SRX100 for the example.


Configuration
1. Edit the 'Junos Superusers' Network Policy and select Vendor Specific in the left hand column. Then select the existing Vendor-Specific RADIUS attribute that was configured in the previous example and select 'edit'.


2. A window will open outlining the attribute information. Select 'add' to insert an additional attribute. The goal is to stop the user "Barney' from executing the command 'request system reboot'. Vendor attribute 'Juniper-Deny-Commands' can be used to deny this command. See the screenshots below for detailed configuration.





Testing
Now that configuration is complete we can test to see if Barney can run the command 'request system reboot'. As you can see below Barney cannot access the command however he can still access the configuration menu.

Below is a packet capture screenshot of the RADIUS traffic that took place to authenticate Barney. In the access-request you can see the newly configured attribute of "Juniper-Deny-Commands' is in the access-reply packet which prevents Barney from running this command.



Conclusion
Remember to take a look at the RADIUS Attributes supported in Junos 11.1 for user authentication page to see all of the attributes that the Juniper SRX supports. I do not plan to setup TACACS+ in the lab but I am curious to hear from anyone who has.