Effective emergency response policies to prevent hacker intrusion

A simple web page damage will show how valuable a detailed Emergency Response Plan is! The experience of being hacked is similar to getting a small, poor income. At least, this is what I recently learned from my own web page being altered and destroyed.

Indeed, our investigation found that a PHP Forum program without patching was running on the damaged server, using PHP exploit, a hacker left a short and friendly message indicating that he had occupied this territory. Although this is a relatively small event, it emphasizes how important it is to have a prepared and wise emergency response plan.

There is a saying that is true: no one will see the value of a strategy without a critical moment. The information response (IR) Plan provides our immediate response, investigation, analysis, and recovery processes. They are like three links in our hands. To ensure their success, we must do the following: Server isolation is a very important server, so we must ensure its installation and isolate it from the network.

We intercept attack behavior between the server and the external network through firewall rules, then we can disable the response switch port and isolate the server. Once isolation is complete, we can pause recording the time for discovery, which will detect the behaviors of hackers and hackers. This is also an important step to provide evidence for court analysis and possible litigation.

Hacker tracking

The hacker did not delete the log, so it took a short time to find that the hacker tried to attack PHP multiple times using a fixed script. What we really want to know is whether a hacker has the permissions of the root user, or uses this server as a stepping stone to attack other systems.

CRC checks for important files tell us that they are not modified or corrupted, and there are no suspicious processes running in memory. We checked the site of the Forum program supplier. Indeed, one week before the attack, the supplier had issued a statement about the vulnerability and released a patch. This is no problem-a week is enough for hackers.

We were shocked that no evidence of PHP attacks was found in our IDS logs. Our IDS vendor told us that before the signature is updated in the next plan, the signature takes about two weeks. That is to say, there is a gap of three weeks before vulnerabilities and attacks are discovered and IDS signatures become available.

Our emergency response strategy is to rebuild any damaged machine regardless of the severity of the incident (without leaving any risk-taking opportunity. The system sets and reinforces Security Based on acceptable general guidelines. We also use a vulnerability scanner to scan machine vulnerabilities to check our work.

Of course, we also use attack software to detect similar machines. Lessons learned from this incident: Make sure your system administrator keeps up with the latest patches (once a month is not enough ), and check logs frequently (once a week is far from enough ).

Security administrators must know what software is installed on each machine so that they can guard against vulnerabilities and vulnerabilities. Do not rely on any unique IDS vendor, because the signature may arrive too late for the first defense range. We consider implementing Tripwire (an intrusion detection system) on public-oriented servers to monitor changes in attributes of important files.

The timeliness of emergency response policies must be maintained at the last point to meet the requirements of the current system. Let everyone know what should be done in an emergency so as to ensure the smooth implementation of remedial measures.