[Dr.WoW] [No.24] GRE-part 2

Latest reply: May 19, 2018 01:28:00 2856 3 1 0

3 Configuring GRE Security Mechanisms

I'm guessing that everyone has a common worry, which is if a malicious user on the Internet forged a GRE packet to look like it was being sent from FW_A to FW_B, wouldn't this pretender then be able to access FW_B's resources? When building the GRE tunnel on FW_A and FW_B, how can we achieve mutual trust? Next we'll discuss GRE's security mechanisms.

1.         Keyword validation

After the GRE tunnel has been configured on the firewall, the firewall won't actually handle every GRE packet it receives, but will instead only handle GRE packets sent by the corresponding terminal device with which it jointly built the GRE tunnel. The "key" segment in the GRE header is used to achieve this function.

When the firewall encapsulates packets with a GRE header, the value of the key bit in the GRE header is set to 1, and the key segment is inserted into the GRE header. When two firewalls build a tunnel, this key segment's value is used by the firewalls to verify each other's identity, and the tunnel can only be built if the value for the key set by the two corresponding terminals is exactly identical.

The figure below shows the GRE header's information. In this header, the fact that the key bit is set to 1 shows that the keyword validation function has been activated, while the "Key:0x00003039" near the bottom is the keyword value (converted to the decimal system this is '12345').

[Dr.WoW] [No.24] GRE-part 2-1334959-1

The steps for configuring keyword validation are very simple. The only thing to pay attention to is that the keywords set for the firewalls on both ends of the tunnel must be identical.

Set the keyword to 12345 on FW_A.

[FW_A-Tunnel1] gre key 12345

Also set the keyword on FW_B to 12345.

[FW_B-Tunnel1] gre key 12345

2.         Checksum validation

Although the firewalls on both ends of the tunnel have now established mutual trust, if the possibility exists for packets to be tampered with by malicious users when they are transmitted over the Internet, how can we guarantee the integrity of packets during transmission? The "checksum" field in the GRE header can be used here.

When a firewall encapsulates a GRE header onto a packet, the GRE header's checksum bit value is set to 1. A checksum is then calculated according to the packet's information, and this checksum is added to the checksum field. When the other terminal of the tunnel receives this packet, it can also compute a checksum based on the packet's information and compare this with the checksum carried by the packet. If the results of the check are identical, then the firewall will accept the packet; if they are not identical, it will discard the packet.

The checksum validation function is one-directional; whether or not the other firewall has enabled the function will not affect the firewall's checksum validation function. In real-world environments, it is advised that this be simultaneously enabled on the firewalls on both ends of the tunnel.

In the screenshot below, the GRE header's checksum bit is 1, meaning that the checksum validation function has been enabled. The "checksum: 0x8f8d" in the figure below is the checksum value.

[Dr.WoW] [No.24] GRE-part 2-1334959-2

The steps for configuring checksum validation are also very simple. To activate checksum validation on FW_A:

[FW_A-Tunnel1] gre checksum

To activate checksum validation on FW_B:

[FW_B-Tunnel1] gre checksum

3.         Keepalive

GRE's security mechanisms can achieve mutual trust between firewalls on both ends of a tunnel, and can guarantee the integrity of packet transmission. However, there is still a problem: if one of a tunnel's terminals has a failure/problem, how can the tunnel's other terminal detect this?

GRE tunnels are a kind of stateless tunnel. This word "stateless" means that one terminal of the tunnel will not determine the state of the other terminal. Or, to put things another way, if a problem arises with one terminal of the tunnel, the terminal on the other end of the tunnel will not be able to detect this. To resolve this problem, GRE tunneling provides the Keepalive mechanism.

As shown in Figure 1-7, after the Keepalive function is activated on FW_A, FW_A will regularly send probe packets to FW_B to detect the state of this other end of the tunnel. If FW_B can be reached, then FW__A will receive a response packet from FW_B, and FW_A will then maintain the tunnel's normal state. If FW_A does not receive a response packet from FW_B, this means that FW_B is unreachable, and FW_A will close the tunnel. This avoids data "black holes" due to one of a tunnel's terminals being unreachable.

Figure 1-7 GRE Keepalive function

[Dr.WoW] [No.24] GRE-part 2-1334959-3 

The Keepalive function is one-directional; whether or not one terminal enables the Keepalive function does not affect the other terminal's Keepalive function. In real-world environments, it is advised that both of a tunnel's firewalls activate this function simultaneously.

The commands to activate the Keepalive function are given below. Here is the command to activate the Keepalive function on FW_A:

[FW_A-Tunnel1] keepalive

To activate the Keepalive function on FW_B:

[FW_B-Tunnel1] keepalive

At this point in our lesson, I'm guessing that everyone thinks that GRE tunnels are a great thing, but actually that's not completely correct. GRE tunneling has its own Achille's heel: it doesn't include a security encryption function. GRE packets without security encryption packets are really only transparent "alter-egos", and the packets are all 'visible' when transmitted in the tunnel. Therefore, in real life we very rarely use GRE by itself, but rather frequently use GRE and IPSec together. As IPSec technology is equipped with very strong encryption functions, this approach resolves GRE's security problems, and this is the GRE over IPS technology that we'll explain below.

4 Approach to Security Policy Configuration

In "Chapter 2 Security Policies," we stated that "both data streams forwarded by a firewall and data streams between a firewall and the outside are controlled by security policies." With this in mind, which interfaces and security zones should we use with GRE? How can we configure security policies for use with GRE? Due to the existence of tunnel interfaces, GRE security policy configuration can be a bit complicated and confusing. But luckily for you, Dr. WoW has a suite of methods that I'll use to help you understand this!

In Figure 1-8, FW_A and FW_B's GE0/0/1 interfaces are connected to private networks, and belong to the Trust zone; the GE0/0/2 interfaces belong to the Untrust zone; the tunnel interface belongs to the DMZ zone.

Figure 1-8 A network's GRE VPN security policy configuration

[Dr.WoW] [No.24] GRE-part 2-1334959-4 

The process for configuring security policies is below:

1.         We first configure an interzone security policy that is as broad as possible, in order to assist GRE adjustment/testing.

FW_A's interzone default packet filtering action is set to "permit":

[FW_A] firewall packet-filter default permit all

FW_B's interzone default packet filtering action is set to "permit":

[FW_B] firewall packet-filter default permit all

2.         After GRE is configured, PC_A pings PC_B. The session table is then checked. Using FW_A as an example:

[FW_A] display firewall session table verbose

 Current Total Sessions : 2

  gre  VPN:public --> public

  Zone: local--> untrust  TTL: 00:04:00  Left: 00:03:37

  Interface: GigabitEthernet0/0/2  NextHop: 1.1.1.2  MAC: 54-89-98-87-22-a4

  <--packets:4 bytes:352   -->packets:5 bytes:460

  1.1.1.1:0-->2.2.2.2:0

 

  icmp  VPN:public --> public

  Zone: trust--> dmz  TTL: 00:00:20  Left: 00:00:00

  Interface: Tunnel1  NextHop: 192.168.2.2  MAC: 00-00-00-00-00-00

  <--packets:1 bytes:60   -->packets:1 bytes:60

  192.168.1.2:22625-->192.168.2.2:2048

The above information shows that PC_A can successfully ping PC_B, and that a GRE session has been successfully and normally established.

3.         ***ysis of the session table allows for the most appropriate security policy for the existing conditions to be selected.

We can see two streams on the session table. One is the ICMP packets from Trust to DMZ, and the other is the GRE packets from Local to Untrust. This allows us to obtain the direction of packets on FW_A, as shown in Figure 1-9.

Figure 1-9 FW_A packet direction

[Dr.WoW] [No.24] GRE-part 2-1334959-5

 

The above figure shows that FW_A needs to configure a Trust-->DMZ security policy that permits packets from PC_A seeking access to PC_B to pass; another Local-->Untrust security policy that permits FW_A and FW_B to establish a GRE tunnel also needs to be configured.

Similarly, we can also obtain the direction for packets on FW_B, as shown in Figure 1-10.

Figure 1-10 FW_B packet direction

[Dr.WoW] [No.24] GRE-part 2-1334959-6

 

The above figure shows that FW_B needs to configure a DMZ-->Trust security policy that permits packets from PC_A seeking access to PC_B to pass; another Untrust-->Local security policy that permits FW_A and FW_B to establish a GRE tunnel also needs to be configured.

When PC_B initiates calls on PC_A, the packet direction is the opposite of the direction when PC_A accesses PC_B, and there is no need to further review this.

To summarize, the security policies that should be configured on FW_A and FW_B under various conditions are shown in Table 1-1, and we should configure the security policies that best match existing conditions as shown in the table.

Table 1-1 Selecting security policies for FW_A and FW_B based upon conditions

Transaction Direction

Device

Source Security Zone

Destination Security Zone

Source Address

Destination Address

Used in

PC_A accesses PC_B

FW_A

Local

Untrust

1.1.1.1/32

2.2.2.2/32

GRE

Trust

DMZ

192.168.1.0/24

192.168.2.0/24

*

FW_B

Untrust

Local

1.1.1.1/32

2.2.2.2/32

GRE

DMZ

Trust

192.168.1.0/24

192.168.2.0/24

*

PC_B accesses PC_A

FW_A

Untrust

Local

2.2.2.2/32

1.1.1.1/32

GRE

DMZ

Trust

192.168.2.0/24

192.168.1.0/24

*

FW_B

Local

Untrust

2.2.2.2/32

1.1.1.1/32

GRE

Trust

DMZ

192.168.2.0/24

192.168.1.0/24

*

*: Use in this instance is related to the transaction type, and can be configured according to actual circumstances (for example: TCP, UDP, and ICMP).

 

 

In GRE scenarios, FW_A and FW_B's tunnel interfaces must be added to security zones, and the security zones the tunnel interfaces belong to determine the direction of packets within a firewall. If the tunnel interface belongs to the Trust zone, then no DMZ-Trust interzone security policy needs to be configured, but this approach also carries security risks. Therefore, I suggest that the tunnel interface be added to a separate security zone, and then configured with the security policy that best matches existing conditions.

4.         Finally, the default packet filtering's action is changed to "deny".

Set FW_A's interzone default packet filtering action to "deny":

[FW_A] firewall packet-filter default deny all

Set FW_B's interzone default packet filtering action to "deny":

[FW_B] firewall packet-filter default deny all

Although the aforesaid adjustment/testing process is a bit difficult, security policies configured in this way are relatively refined, and can adequately ensure the security of firewalls and the internal network.

 

 

To view the list of all Dr. WoW technical posts, click here.

  • x
  • convention:

user_2790689
Created Jun 25, 2015 04:21:23 Helpful(0) Helpful(0)

Thank you.
  • x
  • convention:

wissal
MVE Created Apr 10, 2018 15:47:21 Helpful(0) Helpful(0)

useful document, thanks
  • x
  • convention:

Telecommunications%20engineer%2C%20currently%20senior%20project%20manager%20at%20an%20operator%2C%20partner%20of%20Huawei%2C%20in%20the%20radio%20access%20network%20department%2C%20for%2020%20years%20I%20managed%20several%20types%20of%20projects%2C%20for%20the%20different%20nodes%20of%20the%20network.
w1
Created May 19, 2018 01:28:00 Helpful(0) Helpful(0)

useful document, thanks:)
  • x
  • convention:

Reply

Reply
You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits

Login