I've Been Hacked-What Now
My server has been hacked...what do I do now?
This page will offer suggestions and resources for identifying and eliminating threats to your web servers/applications after a suspected attack.
Anyone interested in contributing is welcome.
- Incident identification/notification may occur from a number of information sources (events):
- Staff reporting unusual activity
- Staff, clients or public reporting a problem
- Technical teams/support discovering evidence of an incident on systems.
- Alerts from IDS, security monitoring systems or anti-virus software, Firewalls or WAFS.
- A Security incident owner must be assigned.
- A point of contact must be available to respond to incidents at all times.
- A security incident owner must track the security incident to remediation and resolution.
- Examples of an incident:
- Virus/malware infection
- Unauthorized system changes
- Unauthorized application/web site changes
- Unauthorized disclosure of client information or information leakage
- Theft or loss of company information/assets
- Examples of an event:
- Reports from intrusion detection system/WAF/Firewall or log scraping system
- Reports from vulnerability scanning/traffic monitoring/performance monitoring
Incident severity :
- Events that cannot be 100% identified as attacks and have no effect on operations;
- False activation of intrusion detection systems, WAF alerts etc
- Non-repeated scans or probing from an external uncontrolled network
- Incidents that have no negative impact on operations. Incidents identified but unsuccessful in an attempt to actively breach information security controls from external or internal standpoint
- Repeated active probing or parameter manipulation from an external or internal source.
- Malware/rogue code/virus that has been successfully contained or removed
- Incidents that have major impact to operations or corporate branding
- Evidence of insider threat with identified motivation by salaried employees or contractors
Containment should be broken into proactive and reactive methods.
These are methods to be used in anticipation of a Web Application server compromise. Web applications have, by comparison to other server types, a much larger attack surface. This is typically because of the fact that by nature they are meant to be internet accessible and require anonymous access in order to be functional. Part of being proactive is segmentation of functions. Your web server should be separate from your application server and separate from your database server. Each tier should be divided by firewalls that only allow the necessary protocols and ports between each tier. In addition, accounts used to communicate between tiers of your web application (WA) should be implemented using the least-privelege method 1.
- All tiers of the WA should be behind firewalls with egress filtering enabled.
- Your web server should never speak directly to your database server.
- All communications should be filtered by a reverse proxy when possible.
- No communications should be allowed between the DMZ segments and the internal company network.
- If database information is required, do so in scheduled DTS packages that are strickly filtered and scrutinized on the internal network.
Event Correlation and Aggregation (Streamlining)
- Cheat Sheet for Server Admin.
- Checking Microsoft Windows® Systems for Signs of Compromise
- SECURITY INCIDENT QUESTIONNAIRE FOR RESPONDERS
- SAN's SysAdmin Cheat Sheet
Questions to Ask
- Was card data compromised?
- Do you need professional legal advice?