Network Security Memorandum

Wednesday, April 15, 2015

Set Up IPSec Site to Site VPN Between Fortigate 60D (3) - Concentrator and Troubleshooting

IPSec Site to Site VPN Configuration Series:

After tested policy based and route based IPSec vpn, this post will do a quick test FortiGate concentrator feature.

The VPN concentrator collects hub-and-spoke tunnels into a group.The concentrator allows VPN traffic to pass from one tunnel to the other through the FortiGate unit. The FortiGate unit functions as a concentrator, or hub, in a hub-and-spoke network.

If the VPN peer is a FortiGate unit functioning as the hub, or concentrator, it requires aVPN configuration connecting it to each spoke (AutoIKE phase 1 and 2 settings ormanual key settings, plus encrypt policies). It also requires a concentratorconfiguration that groups the hub-and-spoke tunnels together. The concentratorconfiguration defines the FortiGate unit as the hub in a hub-and-spoke network.If the VPN peer is one of the spokes, it requires a tunnel connecting it to the hub (butnot to the other spokes). It also requires policies that control its encrypted connectionsto the other spokes and its non-encrypted connections to other networks, such as theInternet.

Topology:

FW3 adds into the our previous topology used in route based and policy based vpn labs. FW3 will act as another spoke , same as FW1. FW2 will be the hub , or concentrator.

Photos:

Configuration:

1. @F3: Since there is a vpn tunnel built between F1 and F2 from previous lab, the first step is going to build another vpn tunnel between F2 and F3.

Create all local address object and remote address objects. Remote objects will include the protected network by F1 and F2.

Create a new rule to allow local network to remote networks with a new ipsec vpn tunnel.

Promote the new rule to the top of the list:

2. @F2. Create new policy rules with a new vpn tunnel betwee F2 and F3.

Create new remote network for F3.

Create a couple of new rules to allow local network to access remote F3's network using a new VPN tunnel F2-F3.

Since there are three local networks behind F2, three new rules will be created.

Note: There is no need to create rule to allow spoke traffic passing among them.

In the VPN - IPSec - Auto Key (IKE), F2-F3 vpn tunnle profile will be there.

At this moment, the tunnel between F2 and F3 is configured and should be up from IPSec monitoring tab.

3. Configure F1 for the traffic between two spokes , F1 and F3.

Add F3's protected network into Firewall Objects - Address - Addresses:

Add the new address object into firewall policy rule:

4. Configure concentrator on F2 hub

Create a new Conentrator from VPN- IPSec - Concentrator.

Give F1-F2-F3 as the name, and select both hub-spoke vpn tunnel as the members:

5. Pint Test:

This is the test from F1's local network host 10.94.70.20. Before concentrator configured at F2, ping to 10.99.144.4 timed out.

As soon as Step 4's concentrator configuration done, ping immediately replied.

Tracert result from 10.94.70.20 to 10.99.144.4:

C:\Documents and Settings\test>tracert 10.99.144.4
Tracing route to 10.99.144.4 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.94.70.4
2 1 ms <1 ms <1 ms 10.94.17.8
3 1 ms 1 ms 1 ms 10.99.144.4
Trace complete.

Troubleshooting Commands:

FGT60D # diagnose vpn tunnel stat
dev=0 tunnel=1 proxyid=1 sa=1 conc=0 up=1

FGT60D # diagnose vpn tunnel list
list all ipsec tunnel in vd 0
------------------------------------------------------
name=f1-f2 ver=1 serial=3 10.94.32.8:0->10.94.17.8:0 lgwy=static tun=tunnel mode =auto bound_if=5
proxyid_num=1 child_num=0 refcnt=8 ilast=3 olast=3
stat: rxp=8 txp=12 rxb=600 txb=720
dpd: mode=active on=1 idle=5000ms retry=3 count=0 seqno=16517
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=_f1-f2_tun_ proto=0 sa=1 ref=2 auto_negotiate=1 serial=1
src: 0:0.0.0.0/0.0.0.0:0
dst: 0:0.0.0.0/0.0.0.0:0
SA: ref=6 options=0000002f type=00 soft=0 mtu=1412 expire=399 replaywin=1024 s eqno=3
life: type=01 bytes=0/0 timeout=1777/1800
dec: spi=1935da05 esp=aes key=32 aa7f520b5457bc16f97c5cfc43483eb1c9b54f853def0 8213ca068506f9cb103
ah=sha1 key=20 b69c401862a7b6320d92e36b0d400f95320852a9
enc: spi=7b5dfde9 esp=aes key=32 0dbcde0df85b6d31dfdceded16314ff1a4ef9977e8fdb bed655ee9ddd0ccc80c
ah=sha1 key=20 f6543bd37cfcbd5ccf881340f4b651940b34684d
dec:pkts/bytes=1/60, enc:pkts/bytes=2/240
npu_flag=03 npu_rgwy=10.94.17.8 npu_lgwy=10.94.32.8 npu_selid=3

FGT60D # diag debug application ike 255

FGT60D # diag debug enable

FGT60D # diaike 0: comes 10.94.32.8:500->10.94.17.8:500,ifindex=5....
ike 0: IKEv1 exchange=Informational id=da8b0eb3b674cd8e/c0b55e04f98318f5:ca3cf88 1 len=92
ike 0: in DA8B0EB3B674CD8EC0B55E04F98318F508100501CA3CF8810000005C85114C19CFD9A0 E3ECE0331A8A6134E1424AD7F8D516523A8D3421F260A17EFFAC75CD4FE3A283CD02832C07B5636B 832E8E976E26A2376FA50F77D94B3D7620
ike 0:f2-f1:104: dec DA8B0EB3B674CD8EC0B55E04F98318F508100501CA3CF8810000005C0B0 00018A23349616A88AF99FFEB71BDB181733E48597075000000200000000101108D28DA8B0EB3B67 4CD8EC0B55E04F98318F5000040B28799820191C3D307
ike 0:f2-f1:104: notify msg received: R-U-THERE
ike 0:f2-f1:104: enc DA8B0EB3B674CD8EC0B55E04F98318F5081005013FB65E04000000540B0 00018A3902503765FF73A4AEB0F8D8DBCCC04A0E1BD63000000200000000101108D29DA8B0EB3B67 4CD8EC0B55E04F98318F5000040B2
ike 0:f2-f1:104: out DA8B0EB3B674CD8EC0B55E04F98318F5081005013FB65E040000005C7E1 54F5BEE4DEB627A700A84B0CB3C0098B5962BFA6CED080EAC0B5BF0E406D2ED7C4EC054B05F97A20 4A1B812D946597958233BBBA2D5CB7A2ABA6EFB70B6CE
ike 0:f2-f1:104: sent IKE msg (R-U-THERE-ACK): 10.94.17.8:500->10.94.32.8:500, l en=92, id=da8b0eb3b674cd8e/c0b55e04f98318f5:3fb65e04
ike 0:f2-f1: link is idle 5 10.94.17.8->10.94.32.8:0 dpd=1 seqno=40ac
ike 0: comes 10.94.32.8:500->10.94.17.8:500,ifindex=5....
ike 0: IKEv1 exchange=Informational id=da8b0eb3b674cd8e/c0b55e04f98318f5:60b967f2 len=92
ike 0: in DA8B0EB3B674CD8EC0B55E04F98318F50810050160B967F20000005CB93CFF645F24AAD1702B89F758E4691C3A67210427BB251023BD3137C605D21D55585C435F25627A09A6242A5C4280EFA4B40E37AEF95224E33308D50465F0F9
ike 0:f2-f1:104: dec DA8B0EB3B674CD8EC0B55E04F98318F50810050160B967F20000005C0B000018F7DB4421DE4D8FE837A092498CC9FC19144E120D000000200000000101108D28DA8B0EB3B674CD8EC0B55E04F98318F5000040B30821732F98702307
ike 0:f2-f1:104: notify msg received: R-U-THERE
ike 0:f2-f1:104: enc DA8B0EB3B674CD8EC0B55E04F98318F508100501C910E3AF000000540B0000189A4BC0E8ACAAD4C3336B442280051149189B1574000000200000000101108D29DA8B0EB3B674CD8EC0B55E04F98318F5000040B3
ike 0:f2-f1:104: out DA8B0EB3B674CD8EC0B55E04F98318F508100501C910E3AF0000005CEC41A52E04D7316299F3DBCE4005D26AE26AFE40F3ADA9ADBF24652041B6836EB942D004846F1B61F528980E9E3B9811CB6AC66B6C6DE439DF98CBC247BA4206
ike 0:f2-f1:104: sent IKE msg (R-U-THERE-ACK): 10.94.17.8:500->10.94.32.8:500, len=92, id=da8b0eb3b674cd8e/c0b55e04f98318f5:c910e3af
ike 0:f2-f1: link is idle 5 10.94.17.8->10.94.32.8:0 dpd=1 seqno=40ad
ike shrank heap by 122880 bytes
ike 0: comes 10.94.32.8:500->10.94.17.8:500,ifindex=5....
ike 0: IKEv1 exchange=Informational id=da8b0eb3b674cd8e/c0b55e04f98318f5:60199215 len=92
ike 0: in DA8B0EB3B674CD8EC0B55E04F98318F508100501601992150000005C202E2B7EC4FD78A9A47A7BAADC85BBBA1240E38168A3E1FF37450B96DA085B38096EFC3352AF7D457DF3D66674BA6848093BFD670234A7E9AC32297AF7A35F73
ike 0:f2-f1:104: dec DA8B0EB3B674CD8EC0B55E04F98318F508100501601992150000005C0B0000188389BC2895680F8618F031B82FB9DA3FEB9C6769000000200000000101108D28DA8B0EB3B674CD8EC0B55E04F98318F5000040B4B478A703A2351A07
ike 0:f2-f1:104: notify msg received: R-U-THERE
ike 0:f2-f1:104: enc DA8B0EB3B674CD8EC0B55E04F98318F5081005013AB0F2D6000000540B0000182AAE9F0D1D6178FF2826ABD38FCE35A17107CD42000000200000000101108D29DA8B0EB3B674CD8EC0B55E04F98318F5000040B4
ike 0:f2-f1:104: out DA8B0EB3B674CD8EC0B55E04F98318F5081005013AB0F2D60000005C84CD92EF75CD2D72941E654D9C1F27D43038A5D56287736BABF6232A5744E413A2A4AC5FFEEA28AA1A51FAD159536748874E6D7F692750CC060C9619E727DD25
ike 0:f2-f1:104: sent IKE msg (R-U-THERE-ACK): 10.94.17.8:500->10.94.32.8:500, len=92, id=da8b0eb3b674cd8e/c0b55e04f98318f5:3ab0f2d6
ike 0:f2-f1: link is idle 5 10.94.17.8->10.94.32.8:0 dpd=1 seqno=40ae

FGT60D # diag debug reset

FGT60D # diag debug disable

Reference:

Fortinet FortiGate 50A Configuration Manual: Vpn Concentrator (hub) General Configuration Steps

Monday, April 13, 2015

Set Up IPSec Site to Site VPN Between Fortigate 60D (2) - Policy-Based VPNs

IPSec Site to Site VPN Configuration Series:

This is the second post for Fortigate IPSec VPN configuration. It will use same topology as previous one.

The implementation will be set up policy based IPSec VPN between two sites.

Topology:

Configuration Steps:

1. Enable Policy Based VPN feature:

By default, Policy-Based IPSec VPN feature is not enabled. We will have to go to System-Config-Feature-Show More to enable it.

2. Go to: Firewall Objects > Address > Address

Create New Address – Internal Subnet - Name it as net_10.94.70.0_local
Enter local subnet: 10.94.70.0/24
Select internal interface

3. Create New Address – Remote Subnet - Name it as net_10.94.66.0_Remote

Enter Remote Subnet: 10.94.66.0/24
Enter wan1 Interface

4. Go to Policy > Policy > Policy

Create New
Select VPN Policy Type
Select IPsec Subtype
Select the local interface - internal, and Local Protected Subnet net_10.94.70.0_local
Select the wan interface - wan1, and remote protected Subnet net_10.94.66.0_remote
Set service to all
Select create new VPN Tunnel.
Choose Site-to-Site and Name it as f1-f2
Put FW2's wan1 ip 10.94.17.8 as Remote FortiGate IP.
Enter Preshared Key
Check the box to allow traffic to be initiated from the remote site

Note: If you choose use Existing directly, sometimes, you will not see your pre-configured VPN tunnel in the list. Create a new vpn tunnel from here always works.

5. Move the policy to the top of the list

6. FW2's Configuration

a. FW2's Firewall Objects - Address-Addresses
There are three local networks defined in here, including all local subnets 10.94.64.0/24, 10.94.66.0/24 and 10.94.144.0/24

b. Three policy rules defined for three different local networks. Remote destination network are same, which is 10.94.70.0/24. All those three rules are using same IPSec vpn tunnle f2-f1, which is defined in step 4.

7. Verify VPN Configuration and Monitoring VPN Tunnel

Note: There is no phase 2 in the Auto Key (IKE) configuration.
Verified ping from 10.94.70.20 to 10.94.66.4

Reference:

Using policy-based IPsec VPN for communication between offices

Set Up IPSec Site to Site VPN Between Fortigate 60D (1) - Route-Based VPNs

IPSec Site to Site VPN Configuration Series:

Fortigate firewall supports two types of site-to-site IPSec vpn based on FortiOS Handbook 5.2, policy-based or route-based. There is little difference between the two types. However there is a difference in implementation. A route-based VPN creates a virtual IPsec network interface that applies encryption or decryption as needed to any traffic that it carries.That is why route-based VPNs are also known as interface-based VPNs. A policy-based VPN is implemented through a special security policy that applies the encryption you specified in the Phase 1 and Phase 2 settings.

Route-based VPNs:
For a route-based VPN, you create two security policies between the virtual IPsec interface and the interface that connects to the private network. In one policy the virtual interface is the source. In the other policy the virtual interface is the destination. The Action for both policies is Accept. This creates bidirectional policies that ensure traffic will flow in both directions over the VPN.

Policy-based VPNs:
For a policy-based VPN, one security policy enables communication in both directions. You must select IPSEC as the Action and then select the VPN tunnel you defined in the Phase 1 settings. You can then enable inbound and outbound traffic as needed within that policy, or create multiple policies of this type to handle different types of traffic differently. For example HTTPS traffic may not require the same level of scanning as FTP traffic.

In this lab part 1, Route-Based VPNs will be configured between FW1 and FW2.

Topology:

1. Two Fortigate 60Ds - FW1 and FW2
2. Switch and Router for routing and connections
3. FW1 has WAN1 IP 10.94.32.8/24, Internal IP 10.94.70.4/24
4. FW2 has WAN1 IP 10.94.17.8/24, Internal IP 10.94.66.4/24, WAN2 IP 10.94.64.4/24, DMZ IP 10.94.144.4/24

Object:

Build IPSec Tunnel between FW1 and FW2 for traffic between FW1's Internal network 10.94.70.0/24 and FW2's three internal networks (10.94.66.0/24, 10.94.64.0/24, 10.94.144.0)

Devices:

Basic Configuration:

@FW1 and FW2: FortiOS 5.0

FW2's configuration steps are exactly same as FW1.

a. Interface Configuration:

wan1: 10.94.32.4/24
internal: 10.94.70.4/24

b. VPN-IPsec-Auto Key (IKE)

Create new Phase 1:

Note: Local Interface is wan1, not internal. Most configuration is by default. Phase1 policy name is FW1-FW2_VPN, which will be used as Interface name for IPSec Traffic later.

Create new Phase 2:

Note: You do not have to specify source / destination address.

c. Creating local and remote network address (interesting traffic to be protected by IPSec VPN)

Note: Remote network segment is on IPSec Interface. This step has to be done before creating firewall policy. Else you will get the entry is being used error when you put FW1-FW2_VPN on the Interface.

d. create two firewall rules in the policy:

One is from Internal network segment to Remote network. Another one is from Remote network to Internal network. Please keep priority of the rule order in mind. You may need to manual adjust your rule order. Usually IPSec Traffic will be put on top of other rules, except management rule.

e. Create Route for Interesting traffic:

The remote network segment will be routed to IPSec Interface FW1-FW2_VPN

f. Monitor IPSec Tunnel:

Reference:

Thursday, March 26, 2015

Troubleshooting Java HTTPS Security Warning Message

One of our Internal Website is always having a Security Warning message when using Internet Explorer https to it, but this message is not showing when using Google Chrome.

Symptoms:

As following screenshot shows, a pop-up window will ask you "Do you want to Continue? The connection to this website is untrusted".

Click More Information link:

The Warning message will warm you a Risk;

"This application will run with unrestricted access which may put your computer and personal information at risk. The information provided is unreliable or unknown so it is recommended not to run this application unless you are familiar with its source.

Unable to ensure the certificate unsed to identify this application has not been revoked.

The digital signature for this application was generated with a certificate from a trusted certificate authority, but we are unable to ensure that it was not revoked by that authority."

Lets drill down again to view Certificate Details:

From the certificate chain, we can see the local certificate was issued by Verisign G4, Verisign G4 certificate was issued by Verisign G5 (expiring date is Jul 16 2036).

I were able to find out this G5 certificate from Certificate button at IE's Content tab:

Interesting thing is when I use Google Chrome, there is no warning at all. But I did found an Interesting thing on the Google Chrome session:

The connection to this website is using TLS1.0 , which is obsolete cryptography.

Solutions:

From previous More Information of warning message screenshot, we could find out it is coming from Java, since at the bottom, it lets us to visit Java.com for more details. Also it mentioned the certificate could not be verified if revoked before. This warning message must relate to Java's TLS Revocation Settings.

I went back to Java Control Panel and found out there is one setting for "TLS Certificate Revocation". After changed it to Do not check. This warning message is gone.

Another solution for this is to change server side to use ssl only. I will keep post once get more information regarding this Java security warming message issue. If you have any better idea why Google Chrome is always fine before any change, please let me know. Appreciated it.

Monday, March 23, 2015

Vulnerability Mitigation - Plaintext Management Interfaces Accessible On Cisco Device

Recently, during an Qualys external Scanning, there is a couple of Vulnerability found which is relate to Plaintext Management Interface. That is because of Telnet port 2002, 9002 is opened on Internet.

It was mentioned before in my previous post. This post just adds more information regarding vulnerability details and how those external scanning tools are responding this vulnerability.

Issues:

In Qualys PCI Scanning report, it lists this vulnerability detail as following:

Plaintext Management Interfaces Accessible On Cisco Device port 2002/tcp
PCI COMPLIANCE STATUS
PCI Severity: MED
FAIL
VULNERABILITY DETAILS
CVSS Base Score: 4 AV:N/AC:L/Au:S/C:P/I:N/A:N
CVSS Temporal Score: 3.6 E:F/RL:W/RC:C
Severity: 3
QID: 38250
Category: General remote services
CVE ID: -
Vendor Reference: -
Bugtraq ID: -
Last Update: 10/31/2012
THREAT:
The target is determined to be a Cisco device, which uses protocols such as HTTP, TELNET, rlogin, FTP, and SNMP for configuration management.
These services can be accessed and are an invitation for malicious users to break in.
The port string mentioned with this vulnerability should identify the service in question.
IMPACT:
Malicious users can exploit this vulnerability to deploy a range of known attacks against accessible services. Brute force attacks such as password
guessing and Denial Of Service are also possible.
SOLUTION:
Consider taking the following precautionary measures:
Disable services that are not needed.
Consider putting access controls on these services. Access controls can be put together using the features in the device (if available) or using an
external firewall.
Do not use default passwords and replace them with hard to guess passwords. Change passwords frequently.
RESULT:
Service name: TELNET(Cisco) on TCP port 2002.

Plaintext Management Interfaces Accessible On Cisco Device port 9002/tcp
PCI COMPLIANCE STATUS
PCI Severity: MED
FAIL
VULNERABILITY DETAILS
CVSS Base Score: 4 AV:N/AC:L/Au:S/C:P/I:N/A:N
CVSS Temporal Score: 3.6 E:F/RL:W/RC:C
Severity: 3
QID: 38250
Category: General remote services
CVE ID: -
Vendor Reference: -
Bugtraq ID: -
Last Update: 10/31/2012
THREAT:
The target is determined to be a Cisco device, which uses protocols such as HTTP, TELNET, rlogin, FTP, and SNMP for configuration management.
These services can be accessed and are an invitation for malicious users to break in.
The port string mentioned with this vulnerability should identify the service in question.
IMPACT:
Malicious users can exploit this vulnerability to deploy a range of known attacks against accessible services. Brute force attacks such as password
guessing and Denial Of Service are also possible.
SOLUTION:
Consider taking the following precautionary measures:
Disable services that are not needed.
Consider putting access controls on these services. Access controls can be put together using the features in the device (if available) or using an
external firewall.
Do not use default passwords and replace them with hard to guess passwords. Change passwords frequently.
RESULT:
Service name: TELNET(Cisco) on TCP port 9002.

Screenshots:

R1#show control-plane host open-ports
Active internet connections (servers and established)
Prot Local Address Foreign Address Service State
tcp *:22 *:0 SSH-Server LISTEN
tcp *:23 *:0 Telnet LISTEN
tcp *:2002 88.198.46.51:58719 TCP Protocols ESTABLIS
udp *:123 *:0 NTP LISTEN
udp *:4500 *:0 ISAKMP LISTEN
udp *:161 *:0 IP SNMP LISTEN
udp *:162 *:0 IP SNMP LISTEN
udp *:1975 *:0 IPC LISTEN
udp *:57430 *:0 IP SNMP LISTEN
udp *:500 *:0 ISAKMP LISTEN

Root Cause:

Based on my search, it looks like the Line 2 is used to communicate between the routers and Embedded Service Engine on the Cisco ISR G2 routers.

The article from itcertnotes provides some solutions.

Complete disable line 2 access
put an access list on the Line 2 for IPv4 and IPv6.

Solution:

Since Embedded Service Engine is not used that much, there is no need to configure an IP address and put a access-list to restrict access. The simplest solution is to complete disable the access to line 2.

line 2

transport input none

Reference:

Close Cisco IOS TCP Ports 23, 2002, 4002, 6002, and 9002 from Network Ports Scanning

Pages

Wednesday, April 15, 2015

Set Up IPSec Site to Site VPN Between Fortigate 60D (3) - Concentrator and Troubleshooting

Topology:

Photos:

Configuration:

1. @F3: Since there is a vpn tunnel built between F1 and F2 from previous lab, the first step is going to build another vpn tunnel between F2 and F3.

Create all local address object and remote address objects. Remote objects will include the protected network by F1 and F2.

2. @F2. Create new policy rules with a new vpn tunnel betwee F2 and F3.

3. Configure F1 for the traffic between two spokes , F1 and F3.

4. Configure concentrator on F2 hub

5. Pint Test:

Troubleshooting Commands:

Reference:

Monday, April 13, 2015

Set Up IPSec Site to Site VPN Between Fortigate 60D (2) - Policy-Based VPNs

Topology:

Configuration Steps:

1. Enable Policy Based VPN feature:

2. Go to: Firewall Objects > Address > Address

3. Create New Address – Remote Subnet - Name it as net_10.94.66.0_Remote

4. Go to Policy > Policy > Policy

5. Move the policy to the top of the list

6. FW2's Configuration

7. Verify VPN Configuration and Monitoring VPN Tunnel

Reference:

Set Up IPSec Site to Site VPN Between Fortigate 60D (1) - Route-Based VPNs

Topology:

Object:

Devices:

Basic Configuration:

@FW1 and FW2: FortiOS 5.0

a. Interface Configuration:

b. VPN-IPsec-Auto Key (IKE)

Create new Phase 1:

c. Creating local and remote network address (interesting traffic to be protected by IPSec VPN)

d. create two firewall rules in the policy:

e. Create Route for Interesting traffic:

f. Monitor IPSec Tunnel:

Reference:

Thursday, March 26, 2015

Troubleshooting Java HTTPS Security Warning Message

Symptoms:

Solutions:

Monday, March 23, 2015

Vulnerability Mitigation - Plaintext Management Interfaces Accessible On Cisco Device

Issues:

Screenshots:

Root Cause:

Solution:

Reference: