juniper check_point elektronika, Publikacje z Informatyka

Pobierz juniper check_point elektronika i więcej Publikacje w PDF z Informatyka tylko na Docsity!

Education Services Courseware

LAB GUIDE

Lab Guide

Lab 3–2 • Implementing AppSecure

Part 1: Verifying Access to the CLI and Client

In this lab part, you will become familiar with the access details used to access the lab

equipment. Once you are familiar with the access details, you will use the CLI to log in to your

designated station. Then, you will load the starting configuration for lab 3. Then, you verify that

you can log in to the Client and confirm that FTP and Web browsing are available on the desktop.

Note

You will only be able to FTP and Web browse within the

constraints that are created on the server.

Note

Depending on the class, the lab equipment used might be

remote from your physical location. The instructor will

inform you as to the nature of your access and will provide

you the details needed to access your assigned device.

Step 1.

Consult the Management Network Diagram to determine the management address of your

devices.

Question: What are the management addresses assigned to

your devices?

Answer: The answer varies. The sample hostname and IP

address used in the output examples in this lab are for vSRX-1,

which uses 172.25.11.1 as its management IP address. The

actual management subnet might vary between delivery

environments.

Step 1.

Access the CLI of vSRX-1 using either the console, Telnet, or SSH as directed by your instructor.

Refer to the management network diagram for the IP address associated with vSRX-1.

Step 1.

Log in to the vSRX-1 device with the username lab and a password of lab123. Note that both

the name and password are case-sensitive. Enter configuration mode and load the reset

configuration file using the load override ajsec/lab3-start.config command.

After the configuration has been loaded, commit the changes before proceeding.

vSRX-1 (ttyu0)

login: lab Password:

--- JUNOS 15.1X49-D70.3 built 2016-12-13 15:11:29 UTC lab@vSRX-1> configure

Implementing AppSecure • Lab 3–

Entering configuration mode

[edit] lab@vSRX-1# load override ajsec/ lab3-start.config

[edit] lab@vSRX-1# commit commit complete

[edit] lab@vSRX-1#

Step 1.

Access the CLI of vSRX-2 using either the console, Telnet, or SSH as directed by your instructor.

Refer to the management network diagram for the IP address associated with vSRX-2.

Step 1.

Log in to the vSRX-2 device with the username lab and a password of lab123. Note that both

the name and password are case-sensitive. Enter configuration mode and load the reset

configuration file using the load override ajsec/lab3-start.config command.

After the configuration has been loaded, commit the changes before proceeding.

vSRX-2 (ttyu0)

login: lab Password:

--- JUNOS 15.1X49-D70.3 built 2016-12-13 15:11:29 UTC lab@vSRX-2> configure Entering configuration mode

[edit] lab@vSRX-2# load override ajsec/ lab3-start.config

[edit] lab@vSRX-2# commit commit complete

[edit] lab@vSRX-2#

Part 2: Configuring AppFW and AppID Features

In this lab part, you configure an AppFW rule set to block FTP traffic that is being disguised as

Hypertext Transfer Protocol (HTTP) traffic on TCP port 8080. Then, you will verify that this traffic

is being blocked as intended.

Implementing AppSecure • Lab 3–

Question: Based on the output, which types of traffic does

vSRX-1 permit?

Answer: The vSRX-1 device is allowing HTTP using the default

TCP port 80, HTTP traffic using TCP port 8080, and DNS traffic

from the Untrust to Server zones.

Question: Will the HTTP policy block non-HTTP traffic that is

using TCP ports 80 or 8080 as the destination port?

Answer: No. The HTTP policy is only examining the traffic up to

Layer 4. As long as TCP ports 80 or 8080 are used as the

destination port, any application can be used.

Step 2.

Open a session to the Client device.

From the session established with the Client device, double-click the gFTP client icon that is on

the desktop.

Note

The gFTP client might resolve the

ajsecserver.ajsec.juniper.net FQDN to the

utmserver.utm.juniper.net FQDN. Both FQDNs resolve to

the same server so do not worry if this happens.

Lab 3–6 • Implementing AppSecure

Lab 3–8 • Implementing AppSecure

Step 2.

Return to the open session with the Client device.

From the open session with the Client device, disconnect from the current FTP session attempt.

Then, open an FTP session to the ajsecserver.ajsec.juniper.net URL and use port

8080 as the destination port. To log in, use the username of lab and password of lab.

Note

If you are unable to disconnect the current session you

might have to close the gFTP application and start it again.

Step 2.

Return to the open session with vSRX-1.

From the open session with vSRX-1, examine the session table by issuing the run show

security flow session command.

[edit security policies] lab@vSRX-1# run show security flow session Session ID: 4756, Policy name: Untrust-HTTP/5, Timeout: 1740, Valid In: 172.16.1.100/42676 --> 172.16.10.100/8080;tcp, Conn Tag: 0x0, If: ge-0/0/3.0, Pkts: 10, Bytes: 576, Out: 172.16.10.100/8080 --> 172.16.1.100/42676;tcp, Conn Tag: 0x0, If: ge-0/0/ 4.0, Pkts: 9, Bytes: 670, Total sessions: 1

Implementing AppSecure • Lab 3–

Question: Did the traffic make it through vSRX-1? Why or why

not? Which security policy did the traffic use?

Answer: Yes, the traffic made it through. This traffic appears to

be HTTP traffic that is using TCP port 8080 and is using the

Untrust-HTTP security policy, even though it is FTP traffic.

Question: Is this behavior a security threat?

Answer: Yes. An attacker could use this information to send

malicious traffic toward the internal server.

Question: How can you stop this type of unwanted traffic?

Answer: To stop the unwanted traffic, you can configure an

AppFW rule set that inspects the Layer 7 data.

Step 2.

Over the next couple of steps, you will examine the AppID database for application signatures

that are suitable for your situation.

Look for HTTP-related application signatures in the AppID database by issuing the run show

services application-identification application summary | match

http command.

[edit security policies] lab@vSRX-1# run show services application-identification application summary | match http junos:SOCKS2HTTP No 927 3 junos:HTTP-TUNNEL No 750 1 junos:HTTP2 No 2553 5 junos:ALIWANGWANG-HTTP No 11863 1 junos:CLOUDME-HTTP No 1471 2 junos:RYPPLE-HTTP No 11151 4 junos:BAIDU-HI-HTTP No 11859 3 junos:HTTP No 67 5 junos:DIASPORA-HTTP No 11065 1 junos:MMS-OVER-HTTP No 116 3 junos:VODDLER-HTTP No 573 1 junos:QQGAMES-HTTP No 11164 3 junos:VIBER-HTTP No 597 5 junos:YAHOO-FINANCE-HTTP No 11896 3 junos:GYGAN-HTTP No 10913 1 junos:WECHAT-HTTP No 12010 4

Implementing AppSecure • Lab 3–

Client-to-server Order: 5

Question: Could this application signature be useful in your

situation?

Answer: Yes. From the description and the parameters in the

port mapping and signature section, this application signature

could possibly help.

Question: Should you consider any other application

signatures?

Answer: The answer to this question depends on whether you

plan to create a blacklist or whitelist AppFW rule set. In this

situation, a whitelist approach is best because vSRX-1 should

only have to worry about processing HTTP traffic through an

AppFW rule set.

Step 2.

Navigate to the [edit security application-firewall] hierarchy level and

configure a rule set to only permit HTTP traffic and deny all other traffic. Then, return to the

[edit security policies global policy Untrust-HTTP] hierarchy level and

apply the AppFW rule set to the HTTP security policy. Also, configure the HTTP security policy to

log session initialization attempts and session closures.

[edit security policies] lab@vSRX-1# up 1 edit application-firewall rule-sets protect-server

[edit security application-firewall rule-sets protect-server] lab@vSRX-1# set rule HTTP match dynamic-application junos:HTTP

[edit security application-firewall rule-sets protect-server] lab@vSRX-1# set rule HTTP then permit

[edit security application-firewall rule-sets protect-server] lab@vSRX-1# set default-rule deny

[edit security application-firewall rule-sets protect-server] lab@vSRX-1# top edit security policies global policy Untrust-HTTP

[edit security policies global policy Untrust-HTTP] lab@vSRX-1# set then permit application-services application-firewall rule-set protect-server

[edit security policies global policy Untrust-HTTP] lab@vSRX-1# set then log session-init session-close

Lab 3–12 • Implementing AppSecure

[edit security policies global policy Untrust-HTTP] lab@vSRX-1#

Question: If you commit the configuration at this point, will the

AppFW logs be recorded locally on vSRX-1?

Answer: The answer depends on what is configured under the

syslog files. If you have a syslog file with the correct severity and

facility levels configured, the answer is yes. If the correct

severity and facility is not configured, the answer is no.

Step 2.

Navigate to the [edit system syslog] hierarchy level and configure the AppSecure-log

file to log messages with the severity and facility levels of any any. Then, configure the log file

to only match messages that contain the RT_FLOW tag. Commit the configuration when you are

finished.

[edit security policies global policy Untrust-HTTP] lab@vSRX-1# top edit system syslog

[edit system syslog] lab@vSRX-1# set file AppSecure-log any any

[edit system syslog] lab@vSRX-1# set file AppSecure-log match RT_FLOW

[edit system syslog] lab@vSRX-1# commit commit complete

[edit system syslog] lab@vSRX-1#

Step 2.

Return to the open session established with the client.

From the open session established with client, disconnect the previous FTP attempt. Then,

attempt the FTP connection using port 8080 again.

Lab 3–14 • Implementing AppSecure

Question: Is the AppFW rule set denying the FTP session?

Answer: The output suggests that the FTP session is being

denied. However, although the output shows that the default

rule is being hit, it does not specifically note exactly what is

being blocked.

Step 2.

Examine the ASC with the run show service application-identification

application-system-cache command to determine whether there is a result for the

recent FTP traffic.

[edit system syslog] lab@vSRX-1# run show service application-identification application-system-cache Application System Cache Configurations: application-cache: on cache-entry-timeout: 3600 seconds pic: 0/ Logical system name: 0 IP address: 172.16.10.100 Port: 8080 Protocol: TCP Application: FTP Encrypted: No Classification Path: IP:TCP:FTP

Question: What information does the output display?

Answer: The output displays that the FTP session is being

recorded in the ASC. The output also shows the destination port

of 8080.

Step 2.

Examine the AppSecure-log for the results of the session messages that relate to the FTP

session by issuing the run show log AppSecure-log command.

[edit system syslog] lab@vSRX-1# run show log AppSecure-log Feb 15 23:26:23 vSRX-1 mgd[26488]: UI_CFG_AUDIT_SET: User 'lab' set: [system syslog file AppSecure-log match] "RT_FLOW -> "RT_FLOW" Feb 15 23:26:23 vSRX-1 mgd[26488]: UI_CMDLINE_READ_LINE: User 'lab', command 'set file AppSecure-log match RT_FLOW ' Feb 15 23:27:22 vSRX-1 RT_FLOW: RT_FLOW_SESSION_CREATE: session created 172.16.1.100/41140->172.16.10.100/8080 0x0 None 172.16.1.100/ 41140->172.16.10.100/8080 0x0 N/A N/A N/A N/A 6 Untrust-HTTP(global) Untrust Server 6179 N/A(N/A) ge-0/0/3.0 UNKNOWN UNKNOWN UNKNOWN Feb 15 23:27:22 vSRX-1 RT_FLOW: RT_FLOW_SESSION_DENY: session denied 172.16.1.100/ 41140->172.16.10.100/8080 0x0 None 6(0) Untrust-HTTP(global) Untrust Server FTP UNKNOWN N/A(N/A) ge-0/0/3.0 No appfw deny

Implementing AppSecure • Lab 3–

Feb 15 23:27:22 vSRX-1 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed application failure or action junos-appfw: 172.16.1.100/41140->172.16.10.100/8080 0x0 None 172.16.1.100/41140->172.16.10.100/8080 0x0 N/A N/A N/A N/A 6 Untrust-HTTP(global) Untrust Server 6179 2(112) 2(132) 1 FTP UNKNOWN N/A(N/A) ge-0/0/3.0 No May 10 17:26:28 vSRX-1 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed application failure or action: 172.16.1.100/54734->172.16.10.100/8080 None 172.16.1.100/ 54734->172.16.10.100/8080 None None 6 HTTP Untrust Trust 24206 4(226) 2(132) 1 FTP UNKNOWN N/A(N/A) ge-0/0/8.0 No

Question: What is the reason given for closing the session?

Answer: The message of application failure or

action is given as the reason for closing the session.

Part 3: Building Custom Application Signatures

In this lab part, you will configure a custom application signature that you will use in an AppFW

rule set to block specific traffic. Then, you will verify that this traffic is being blocked by the

AppFW rule set.

Step 3.

Return to the open session established with the client.

From the open session established with client, open the Web browser by double-clicking the

Firefox icon. If necessary, you can close the gFTP client now.

Implementing AppSecure • Lab 3–

[edit system syslog] lab@vSRX-1# top edit services application-identification application AJSEC-FILES

[edit services application-identification AJSEC-FILES] lab@vSRX-1#

Step 3.

Configure the application signature to match on HTTP and then configure signature s-01 to

match on the http-header-host context within the m01 member.

[edit services application-identification AJSEC-FILES] lab@vSRX-1# set over HTTP signature s-01 member m01 context http-header-host

Step 3.

Configure member m01 with the pattern match of

"(.*.)?(ajsecserver.ajsec.juniper.net)".

[edit services application-identification AJSEC-FILES] lab@vSRX-1# set over HTTP signature s-01 member m01 pattern _"(..)?(ajsecserver.ajsec.juniper.net)"_*

Step 3.

Set the direction of member m01 to the client-to-server value.

[edit services application-identification application AJSEC-FILES] lab@vSRX-1# set over HTTP signature s-01 member m01 direction client-to-server

Step 3.

Configure the new member m02 with the context of http-url-parsed within the s-

signature, the pattern of /files/ , and the direction of client-to-server.

[edit services application-identification AJSEC-FILES] lab@vSRX-1# set over HTTP signature s-01 member m02 context http-url-parsed

[edit services application-identification AJSEC-FILES] lab@vSRX-1# set over HTTP signature s-01 member m02 pattern /files/

[edit services application-identification AJSEC-FILES] lab@vSRX-1# set over HTTP signature s-01 member m02 direction client-to-server

[edit services application-identification AJSEC-FILES] lab@vSRX-1# show over HTTP { signature s-01 { member m01 { context http-header-host; pattern "(.*.)?(ajsecserver.ajsec.juniper.net)"; direction client-to-server; } member m02 { context http-url-parsed; pattern /files/; direction client-to-server; } } }

Lab 3–18 • Implementing AppSecure

Step 3.

Navigate to the [edit security application-firewall rule-sets

protect-server] hierarchy level. Then, create the rule AJSEC-FILES that denies traffic

when it matches on the AJSEC-FILES application signature. Examine the rule set after you

have added the new rule.

[edit services application-identification AJSEC-FILES] lab@vSRX-1# top edit security application-firewall rule-sets protect-server

[edit security application-firewall rule-sets protect-server] lab@vSRX-1# set rule AJSEC-FILES match dynamic-application AJSEC-FILES

[edit security application-firewall rule-sets protect-server] lab@vSRX-1# set rule AJSEC-FILES then deny

[edit security application-firewall rule-sets protect-server] lab@vSRX-1# show rule HTTP { match { dynamic-application junos:HTTP; } then { permit; } } rule AJSEC-FILES { match { dynamic-application AJSEC-FILES; } then { deny; } } default-rule { deny; }

[edit security application-firewall rule-sets protect-server] lab@vSRX-1#

Question: If you commit the configuration now, what will happen

to the traffic that would match the AJSEC-FILES signature you

just created?

Answer: The traffic would first match the HTTP rule in the rule

set and it would be allowed through vSRX-1. The traffic would

never hit the AJSEC-FILES rule.