Security devices: Key Points of firewall negligence

We have had such an experience in most of our careers-I mean you think it is enough to let you lose your job. My first major mistake was to restart all the routers on campus, not one by one, but one by one. I wrote a script to install a security update for all routers, and then restart these routers in turn-at least I thought so. In fact, my script is incorrect and the wait time between routers is missing. At that time, I thought I was about to be fired, but thank God, I didn't. Some major accidents often help us to learn. We all know more or less about crisis management, and everything can be recovered from online backup. My boss spent several hours teaching me how to correctly check whether the network is running normally. The good news is that most of the time, the mistakes we make are not so serious, and the bad news is that many mistakes won't be shown at the time. That is to say, such mistakes will be left behind and cannot be found. They may be several weeks, months, or years until one day they have triggered a serious disruption accident, or we can be summoned by auditors. In the first line of network security, firewall management is such a behavior-when you change rules and configuration files, a small error may cause you a huge problem. The following are some common mistakes: 1. Create a meaningless firewall group. A firewall administrator has more than half of the Rule permissions when adding the device to the network. Later, we named Joe_Montana with the name of a star. in any case, the administrator needs to add a device to the network, and then adds the IP address of the device to the frequently-used authorization rules, add to such a group. Finally, these rule libraries make Auditors seem okay, because there are no rules like "arbitrary", but in fact many firewall vulnerabilities are buried. Firewall rules become meaningless. Once audited and rectified, clearing these rule libraries is a thankless task and takes many months to solve the rule repository problem, to securely and appropriately map to business needs. 2. Never upgrade your firewall software. an astonishing number of organizations use outdated firewall software. When asked why, we often get a few similar replies: "We need to maintain version stability" or "the firewall cannot be removed for upgrade "... And so on. In fact, there is a reason for Firewall vendors to upgrade their own software. You do not need to install the latest version of the firewall, but if you are running an outdated version of 15 or 20, or have not updated the version for 7 or 8 years, immediately stop complaining and start updating! 3. We have heard about the use of the wrong technology to break square dingtalk into a circle hole. This is also true in the firewall industry. A network security administrator is fiercely arguing with their auditors because they have a firewall placed in front of a secure WEB server, which forms a dual authentication: a password and a firewall. This guy's creativity Can Be A, but the firewall (itself) is not A dual authentication solution. Dual identity authentication requires your user to have a token and password. 4. Unexpected shutdown events I have heard of such an unexpected shutdown event. The firewall administrator is collecting some firewall data. The Administrator accidentally touched the mouse on the table, and the mouse was hovering over the Start Menu. Just as destined, the mouse activates the Start menu in an incredible way and just hovers over the "close" menu. Yes, that's how the financial company's firewall was shut down. 5. create bad firewall configuration documents you will often hear some firewall administrators are very busy trying to understand what the firewall rules they have done are. As shown in the figure, it is time-consuming to create a firewall document to make yourself busy in the future, or is it time to create a reasonable firewall document? A sloppy firewall document is equivalent to creating a time bomb for yourself. Looking into some administrators who participate in the management of the firewall, they often hear such complaints: "Now I am afraid to adjust my firewall. All the senior managers have left, and we do not know the firewall documents, the meaning of the majority of the names in it, or what these rules are used." 6. Do not use routing as your security policy. I have seen many firewalls like this. When their rule repository is corrected, the vro needs to change accordingly to adapt to new firewall rules. Perhaps this is understandable-when a network in the firewall needs to be rebuilt, the fact is that the network has not changed, but the firewall needs to be changed. There are two kinds of "kidnapping" router errors that often happen at work. In the first case, the firewall does not have a default route. Each route Line is manually added to the firewall, and usually uses the smallest subnet mask. Many devices that are not in the plan will be blocked if no firewall policy is set in the future, cannot pass routing. This sounds great and looks safer, but it is completely unnecessary-if you delete this firewall policy, it will be restored to "ignore all ". This design will make the firewall difficult to manage, and the firewall team will be afraid of making changes, because it will involve a lot of things. Each policy change requires an engineer to check the route. Therefore, each firewall policy change takes too long, which greatly affects network maintenance tasks. Therefore, this is of no practical value to increase security. This is also a case where the Cisco device Administrator group is the most common. For example, an administrator needs to create an access control list that includes any source or target addresses between two devices. They actually mean all the addresses between two devices, not at any time. However, administrators are too lazy to enter addresses. In this way, only by knowing the route table connecting to the firewall can we know the actual meaning of this firewall policy. These need to be kept in mind by the Administrator. For a beginner firewall administrator, it is too difficult to take over the firewall. 7. Using a vrodns DNS object as a firewall policy object many firewalls provide such a function option that allows administrators to insert a DNS object as the source or target address, for example, www.google.com. this sounds good, because google.com can act on so many IP addresses, so that even if the IP address of google.com is changed, my firewall can still act on the address under the domain name. This kind of wrong practice will lead to many risks. Most organizations should consider not to use this practice. First, the firewall is vulnerable to DoS attacks. Can you imagine what will happen when the firewall cannot resolve the google.com domain name? Second, when DNS resolution is performed for all data packets, the firewall needs to find each data packet to determine whether the data packet belongs to google.com, which will greatly waste CPU, memory and network I/O. third, if your DNS server is poisoned, your firewall will allow all botnet commands to pass through and record it as a normal Domain Name