Firewall security management should be paid attention

Each of us has made a mistake in our career. The errors mentioned here are the ones that will immediately cause you to lose your job. For example, a school network administrator has made such a mistake, which directly causes all routers on campus to restart at the same time, rather than one by one. The administrator originally wrote a script to perform a security upgrade on the vro. In the plan, he planned to upgrade and restart the vro one by one, but the result was a restart at the same time. After re-checking the script, he found that the error was not waiting for the vro to restart. Instead, he directly ordered the next vro to perform the upgrade.

In this case, it is almost certainly to be dismissed by the school, but fortunately, the school did not. However, for anyone involved in a catastrophic event, what should be learned from the disaster. We have learned some crisis management knowledge. After the network recovers, it is necessary for us to spend several hours learning how to check whether the network works properly.

Fortunately, most of the time, the mistakes we face are not that serious. Unfortunately, our mistakes may not be immediately discovered, which means they may be lurking for weeks, months, or even years until one day has serious consequences, or the regulatory authority will ask us for further questioning after finding the problem. At the forefront of the network security field, firewall management is a very important area. Any simple error rules or configurations can bring us endless troubles. Next let's take a look at some of the most common errors:

Build meaningless firewall groups

A firewall administrator may contain a specific network object in more than half of the rules. We assume that this object is named "Joe_Montana ". Every time this object needs to access the network, the Administrator adds an IP address for this object, which is the licensed address listed in many licensing rules. This seems okay, because no rule contains the ANY range, but it is actually a big vulnerability. It makes firewall rules meaningless, and it may take several months to thoroughly sort out the firewall rule library to solve this problem.

Never upgrade firewall software

The software used by many companies' firewall devices is outdated. When asked why this problem occurs, most Enterprise Firewall administrators say they want to ensure the stability of the firewall, or do not allow the firewall to be temporarily closed due to upgrades. In fact, firewall product vendors decide to upgrade firewall software for some reason. Even if the enterprise does not have to update the software to the latest version, if it still runs the old version of software before January 1, year 56, or 15-20 old versions of software from the latest version, you should consider starting the upgrade immediately.

Incorrect Technology

Previously, a cyber security administrator had a dispute with the supervisor because the Administrator placed a firewall on the front-end of the company's secure web server as the second layer of protection barrier. According to his ideas, this constitutes a dual authentication mechanism: a user password and a firewall. It can be said that this administrator can get full marks in innovation, but the firewall itself is not a dual-validation solution. Double verification requires that your users have two verifiable objects: known and owned. For example, you know the password and have a token.

Accidental Power Failure

A firewall administrator collects data on a firewall server for a project. The Administrator accidentally touched a few mouse clicks when adjusting the network cable. At this time, the mouse pointer is at the starting position. Then, the cool mouse pointer refers to the shutdown Confirmation window popped up in the center of the screen and the shutdown button in the middle. So the firewall of the finance company was suddenly closed in this case.

Bad document

You may often hear that the firewall administrator complained that they could not understand all the firewall rules. If the Administrator does not provide detailed instructions when setting up firewall rules, it seems that the time and effort will inevitably be spent on understanding these rules. So someone must have heard this: "I'm afraid we have to modify the firewall settings again. The firewall rules set by the former Administrator are not commented, so it is difficult for us to understand their functions ."

Excessive use of Drop rules

In general, if the time is too short, we will establish some rules that are excessively accessed, and then, on the basis of these rules, we will establish a discard rule to discard unallowed data connections. This is because many of our administrators are reluctant to set a precise firewall rule. For example, "allow All DMZ devices to All Internal devices ACCEPT", and then create an "All DMZ devices to Secure Network device DROP" on this rule ". These two rules seem to be okay, but they actually involve a lot of post-problems, because we didn't demonstrate the purpose of creating the rule in the first rule. In the long run, many rules will appear in the firewall rule repository, and more risks may occur when you record or modify rules, or necessary data may be intercepted. In the end, we had to rewrite all the rules in the entire firewall rule repository.

Use routing as a security policy

You may encounter many similar situations. When the firewall rule repository needs to be modified, the routing rules should also be modified. Of course, this phenomenon can be understood if new networks are involved. There are two errors that generally lead to this situation. First, the firewall does not have a default route. All routes are manually entered into the firewall. If the firewall does not have a policy, the minimum subnet mask is used to prevent data from flowing to unrelated devices. This sounds good, but it is completely unnecessary, because if you delete a policy from the modern firewall, the firewall will be restored to deny any. This design will become difficult to manage, and the entire IT team will not dare to modify the firewall settings. If engineers need to check the route settings for each change, it will take too much time and affect the normal business operation of the enterprise. This is not worthwhile for the enterprise.

The second case is most often seen on Cisco devices. The Administrator uses the access control list to manage two interfaces with ANY source or target. In fact, the ANY in this rule is not all addresses, but all addresses after the port. The administrator can understand the rules in the firewall rule repository only when the route table is associated with the firewall. This is too complicated for the administrator.

Use DNS objects in rules

As an option, many firewalls embed a source address or destination address as a DNS object, such as www.google.com. This seems to be wrong because google.com uses a considerable number of IP addresses. Even if google.com changes the IP address, the firewall will allow the data stream of google.com. However, this practice will lead to serious security risks, and we believe that no enterprise can accept them. First, this will make your firewall more vulnerable to DoS attacks. What if I cannot parse google.com? Second, your firewall will waste CPU, memory, and network I/O to determine whether each packet belongs to the google.com domain name. Third, what if the DNS you set is attacked by hackers, and the command and control data containing a malicious address contain a google.com address? In this case, your firewall will allow the botnet to send commands and control data, and record the data as google.com in the firewall log.

Changes made in critical moments

Imagine that if the RAID array on the server is broken, a hard disk will be decommissioned. You have changed a hard disk. During RAID reconstruction, the server cannot provide normal services, but you are not aware of this problem. At this time, your customer has been denied services for 40 hours, And you suffer losses every minute. In addition, customers keep giving up your services, but choose competitors.

When the situation becomes critical, we often begin to change the configurations of various devices: switches, routers, Server Load balancer servers, and firewalls, any link that you suspect has caused the service to be abnormal has been changed. After a long time, someone in the team finally found the problem. Therefore, you need to restore all the changed configurations, but the problem is that no one will remember the previous configuration because the previous situation is too tight, as a result, no one will modify the configuration document. The final result is that you have to spend three days debugging the configurations of each device to the previous state.

I believe that all enterprises do not want this situation to happen. However, it turns out that this situation has occurred from time to time. Even the best-running enterprises have similar problems, especially in firewall configuration. However, through the Automated recovery mechanism, the work that relies on experience is increasingly easy to implement. To know whether your enterprise has this automatic recovery function for network security settings or other security settings, it depends on whether the enterprise has made a clear and detailed quantitative design of the ROI. After all, if there is no clear quantitative statistics on the return on investment for security investment, Who can believe that this enterprise is trustworthy in terms of security?