Actual combat case: The hospital egress router is cut over. Once the intranet device is connected, the router interface cannot be accessed? Amazing!

Background

XX Company is an engineering company specializing in computers/monitoring/networks. It recently received a project to replace the export routes of a local tertiary hospital.

The requirement is very simple. The intranet architecture remains unchanged. All that needs to be done is to cut over and replace the egress route, replacing the original W route with a P route.

The topology is as follows:

Cutover requires "transplanting" the original routing configuration plan to the new router to access the Internet. Cutover requires a single PC trial run rather than blind replacement.

Problem Description

We found a PC on site to connect directly to the LAN side of the router. After making basic configurations such as WAN dial-up + NAT + DHCP services, we connected the broadband to the router WAN port. The PC was able to obtain an IP address and access the Internet normally.

At this time, I plugged the intranet core switch into the router LAN port, and suddenly found that the router could be pinged, but the Web management page could not be accessed!

Comparative test, unplug the core switch of the intranet and connect the PC directly to the router, and it works normally again:

It's amazing that as long as the intranet is connected to the router, the web will be "down". Is there an attack? Let's take a look.

Troubleshooting Analysis

Step 1: Telnet test router http port 80

If the ping is successful, it means the link is normal. Next, we need to confirm whether the port service is still open:

It can be seen that the router's Web is completely down. This "rejection prompt" means that the router actively RSTs the PC http access connection. The corresponding message is also the same:

There are generally two possibilities for a Web service to fail:

• The router is faulty. From the existing analysis, we know that this problem only occurs when the router is connected to the intranet. It works normally when it is disconnected from the intranet, indicating that the device is not faulty.
• The http service is full of "malicious connections". The most common ones are TCP half-connection① and SYN Flood②, a type of "denial of service attack". These two malicious behaviors will consume the service resources of the server, making it unable to provide corresponding services such as http and https.

Remark:

• TCP half-connection: The attacker initiates a large number of TCP connections to the server, but does not respond to the last ACK in the three-way handshake, causing a large number of invalid "TCP half-connections" on the server itself, exhausting its resources and causing service abnormalities;
• SYN Flood: TCP flood attack, the attacker opens a large number of TCP connections to the server port, exhausting its resources and causing service abnormalities.

At present, it seems that the router acting as the gateway may have been attacked by a "denial of service attack". The next step is to check the system status of the router through the serial port.

Step 2: Serial port access to view the router session status

Access the serial port and use the command to view the routing system session status:

I see a large number of TCP port 80 connections in the establish state in the session table. It is obvious that the HTTP service resources of the router are occupied by a large number of connections, resulting in service anomalies. This is a typical SYN Flood attack. A large number of devices in the intranet will look for the gateway port 80 and establish a connection. Is it either a human initiative to access, or some special behavior of some medical devices in the intranet frequently establishing connections?

Step 3: Capture packets to confirm the behavior of intranet terminals

Open wireshark to mirror the uplink port of the core switch (most managed switches support port mirroring):

The captured packets are as follows:

After filtering, we can see that a large number of terminals will actively establish connections with port 80 of the gateway (router).

Solution

After verification with the on-site hospital IT, these were mostly medical terminals such as bed intercoms and call screens. It may be some kind of detection behavior of the device itself to the gateway. Although it seems abnormal, these devices cannot be removed.

If you can't change the terminal, you can only change the router. Currently, the terminal will only access the http port 80 service of the gateway. You can change the http service port to a non-port 80 and try using:

After the modification, connect all the intranet devices to the LAN port, and its Web interface can be opened normally.