Detecting and Countering Server Intrusions - Incident Response
(Page 3 of 4 )
Incidents can and do happen. Security is a weakest link problem, and as long as you’re plugged into the Internet you have to be aware of the dangers and what can happen. So, if an incident does happen you need to be prepared for it. By being prepared you can minimize the damage of an attack and act swiftly instead of wondering what to do next.
So, why would anyone attack you? The answer could be as simple as because they can. However, usually attackers have a reason: there is something they want on your machine. Common attacks against Internet servers include:
- Attacks against the server itself (to gain access)
- Attacks against the content (defacement)
- Attacks against the entity (theft, data, information gathering, defacement, slander)
Knowing which one of these attacks is more likely to happen to your server will help in preparing possible recovery actions and responses.
Have a plan (disaster recovery plan)
Sometimes you have to plan for the worst. Right now, you should stop and think about what you would do if you machine got attacked. Imagine the types of attacks that could happen. What is the worst thing that could happen? Scary, huh? Now imagine how you would respond. What would you do? Who would you call?
By identifying assets, visualizing the types of attack, and thinking of possible outcomes you can come up with a disaster recovery plan that can be executed in the event of an incident:
Identify your assets
What assets do you need to protect? What is on the server that should not fall into the hands of an attacker? How is that information being protected?
Visualize an attack path
How would it happen? What is the worst that could happen? Knowing everything you know about the server, how would you try to break in?
Evaluate the risk of that asset being compromised
What is the risk?
Formulate a response
What’s the best course of action to take if the asset is compromised? Who needs to know; what needs to be done?
Take a reference snapshot of the file system and store it on removable media
In the event of an incident, this will be useful in identifying the extent of the damage.
Create a forensics disk that has known versions of programs, so you know it’s safe to use
A good set of common tools has already been assembled as part of a source forge project called Live View: http://liveview.sourceforge.net/.
Document all your findings
Create a procedure for each potential event and a contacts list.
Report the incident
Contact all the people on the contacts list and notify them of the incident.
HELP! I’ve been hacked!
Don’t panic. Take a deep breath. Everything is going to be OK. Do you have a plan? If you do, now is the time to execute it. If you don’t, we need to try to contain what happened. To do this, we need to retake control of the system using reliable tools:
- Create a forensics toolkit CD complete with all the executables you will need to assess the system—such as Live View (http://liveview.sourceforge.net/).
- Before you unplug anything, create an image of the current state of the system to preserve any evidence.
- Use the forensics toolkit CD.
- Check the file system for commands that may have been tampered with—such as ps , ls , netstat . Do a file integrity scan and perform a file system audit. Check all running processes, and make sure that a root kit or a Trojan is not running. Inspect the logs for evidence.
- Report the incident to the proper authorities.
The main goal is to try to determine the source of the attack. Once that is discovered, you can alter firewall rules and do a more solid job of locking down.
Next: Web Server Hardening >>
More JavaScript Articles
More By O'Reilly Media
|
 This article is excerpted from chapter four of Securing Ajax Applications: Ensuring the Safety of the Dynamic Web, written by Christopher Wells (O'Reilly, 2007; ISBN: 0596529317). Check it out today at your favorite bookstore. Buy this book now.
|
|
