No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade
Knowledge Base

AR151 V2R5 forwarded directed broadcast packets be considered as IP spoof attack

Publication Date:  2019-07-18  |   Views:  747  |   Downloads:  0  |   Author:  SU1102283537  |   Document ID:  EKB1000113862

Contents

Issue Description

Customer has an installed base of 450 computers and 35 servers spread over some 25 sites. These sites are interconnected with two radio technologies.

 

This network until had a "flat network" in which cohabiting 3 segments networks (192.168.1.x / 24, 192.168.5.x / 24, 192.168.7.x / 24). These three address ranges were managed by three legs of our firewall (Sonicwall nsa2400 - Firmware update). Diagram below:

 

To overcome the slowness problems on the network and in the idea of securing our infrastructure, Customer decided to implement subnets per site. And they acquired 18 ar151 Huawei routers. The idea is to remove the firewall beaches 192.168.5.x / 24 and 192.168.7.x / 24 to keep only the subnet 192.168.1.x / 24. They configured several Huawei routers on the same model (1 leg in Lan 192.168.1.x / 24 and another leg in 192.168.x.1 lan / 24). Example: theater network: one tab to the main town in 192.168.1.42/24 (Ethernet0 / 0/2) and a paw 192.168.15.1/24 (Ethernet 0/0/3). Theater internal network machines have ip address 192.168.15.2/24 style.

Infrastructure expected at the end of operations, the diagram below (4 networks represented in the 18 desired)

 

 

The City'snetwork equipment is mainly composed of brand switch Allied Telesis AT-X610 and At8000s (for network heart). These switches have a factory configuration (no IP native vlan VLAN1).
During the implementation of these routers we noticed that to configure a VLAN tab 15 and another VLAN20 did not prevent the transmission of data to the vlan1.

They made 8 of these routers over a weekend before we see the problem on the network. So they have this material immediately replaced by computers using a Linux distribution dedicated to routing. This configuration works without problems. Then found only one brand Huawei router is still on their network. They noticed in their firewall logs this message. The mac address indicated in this screenshot match that of Huawei router.

By adding a second Huawei router on their network, pings degrade instantly to the general cut-off of the entire network.

Alarm Information

We can find the logs on the uplink firewall as following,

Handling Process

1. Check the health status of AR.

Use commands "display arp, display fib, display cpu-usage, display memory-usage" to check the common health items of AR and found that the arp entries is only around 20, and fib table has the correct default route, also the cpu-usage and memory usage is not high. Also from the output of commands "display cpu-defend statistics' we can find that there are no dropped packets recorded.we can consdier that the health of AR router is normal.

2.Check the forwarding status of AR. Create the rules as following to do packets statistic on AR. And ping 100 packets from client 192.168.1.1 to 8.8.8.8 we can find that AR forward the packets out but no feedback. So we consider the forwarding on AR is ok also.

acl number 3999  
rule 5 permit icmp source 192.168.1.1 0
rule 10 permit icmp destination 192.168.1.1 0
#
traffic classifier test operator or
if-match acl 3999
#
traffic behavior test
statistic enable
#
traffic policy test                      
classifier test behavior test
#
interface Ethernet0/0/1
description downlik-to-client
traffic-policy test inbound
traffic-policy test outbound

interface Ethernet0/0/0
description uplink-to-firewall
traffic-policy test inbound
traffic-policy test outbound

 

[AR]dis traffic policy statistics interface Ethernet 0/0/1 inbound

Interface: GigabitEthernet0/0/0
Traffic policy outbound: test
Rule number: 2
Current status: OK!
Item                    Sum(Packets/Bytes)               Rate(pps/bps)
------------------------------------------------------------------------------
Matched                           100/0                           0/0           
   Passed                          100/0                           0/0 

[AR]dis traffic policy statistics interface Ethernet 0/0/1 outbound

Interface: GigabitEthernet0/0/0
Traffic policy outbound: test
Rule number: 2
Current status: OK!
Item                    Sum(Packets/Bytes)               Rate(pps/bps)
------------------------------------------------------------------------------
Matched                           0/0                           0/0           
   Passed                          0/0                           0/0 

[AR]dis traffic policy statistics interface Ethernet 0/0/0 outbound

Interface: GigabitEthernet0/0/0
Traffic policy outbound: test
Rule number: 2
Current status: OK!
Item                    Sum(Packets/Bytes)               Rate(pps/bps)
------------------------------------------------------------------------------
Matched                           100/0                           0/0           
   Passed                          100/0                           0/0 

[AR]dis traffic policy statistics interface Ethernet 0/0/0 inbound

Interface: GigabitEthernet0/0/0
Traffic policy outbound: test
Rule number: 2
Current status: OK!
Item                    Sum(Packets/Bytes)               Rate(pps/bps)
------------------------------------------------------------------------------
Matched                           0/0                           0/0           
   Passed                          0/0                           0/0 

 

3. Check the issue on firewall, We can find that there are many attack logs exist, and the source mac is the mac-address of uplink interface of AR,

the source IP and destination IP is not on AR but on another switch.

4. Analysed packets on the uplink switch which connected AR. We can find that AR received and forward out the packets witch source IP 192.168.7.1 and destination IP 192.168.7.255. (which is not on AR and may received from other devices)


5. Analyze the traffic patch of the packets with source IP  192.168.7.1 to destination 192.168.7.255, and found that all the subnet connected to one switch and that switch have default configuration which has no VLANs configured. That means this kind of broadcast packets would also be received by AR. Then AR consider it as normal packet when received and forward it followed layer 3 forwarding table based on default routings. Then firewall would receive two packets with same source 192.168.7.1 and destination 192.168.7.255, the destination mac is FFF-FFF-FFF , but the source MAC is different
since one of the packets was sent by AR and changed as AR's mac-address.  When firewall received this kind of packets it consider AR as the ip spoof attack source and blocked all the packets.

Root Cause

When AR received directed broadcast packets (eg:source IP:192.168.7.1 source mac: HHH-HHH-HHH, destination IP:192.168.7.255, destination mac: FFF-FFF-FFF), it will forward it as normal layer3 packets and changed the source mac but not drop it directly. It is a forwarding fault for this kind of scenario of AR.

Solution

1 The workaround is to configure traffic filter to block all the packets like the ones with destination IP 192.168.7.255/10.255.255.255, so that AR will not sent this kind of packets to firewall anymore and solved the issue. But there is still a risk because if customer have other subnets configured in the network , we need to configure traffic filter to block this kind of packets also, so we can only consdier it as a workaround, but not final solution.

2. Our RND has released a patch V200R005SPH017 to fix the issue, with the patch there is a commands " broadcast routing disable " added. We can configure this commands under the uplink interface and then AR will not forward this kind of packets anymore to avoid the fault situation.