This appendix contains checklists for your reference. For ease of use, they are separated first by topic (that is, penetration tests checklists and countermeasures checklists), and then by chapter.
The following checklists, which can also be found on the companion CD, are lists of items you should be covering during your penetration tests. Each network environment on which you conduct a penetration test will differ in some way so there may be additional items not covered here; however, consider these checklists as a good baseline.
Check registrar records for non-essential information that could aid attackers.
Determine your organization’s IP network block assignment using the appropriate WHOIS database.
Review each host in your organization’s IP network block assignment.
Review content on your external servers for the presence of non-public data.
Use several search engines to detect nonpublic content on your organization’s external servers.
Review public discussion forums for any leaked information about your organization.
Check for zone transfers both internally and externally.
Try reverse lookups when zone transfer attempts are unsuccessful.
Check for MX records. Ensure that the mail servers are within the scope of the networks you’re allowed to test.
Check for misconfigured firewall rules to mail servers.
Check whether SRV records are available externally.
Check for CNAME records. They often point to important systems.
Check for miscellaneous records.
Disabling NetBIOS over TCP/IP, Computer Browser, or Messenger service on your penetration box will hinder your ability to gather information about other boxes using these services.
Check to see whether you have access to LDAP directories.
Pay attention to hosts with multiple IP addresses—these could be a gateway into other networks.
Host discovery techniques:
ICMP sweeps
UDP sweeps
TCP sweeps
Broadcast sweeps
Network discovery techniques:
Trace routing
Firewalking
TCP connect scans
SYN scans
FIN scans
SYN/ACK scans
ACK scans
XMAS scans
Null scans
Idle scans
UDP scans
FTP bounce scans
Use active and passive fingerprinting techniques to try to identify the target operating system or application.
Check IP implementation:
Type of Service (TOS).
Identification.
Fragmentation flags.
Time-to-Live (TTL).
Protocol.
Options.
Check ICMP implementation:
Information requests.
Timestamp requests.
Address mask requests.
Check TCP responses:
Initial sequence number prediction and patterns.
Unusual combinations of flags sent.
Options.
SYN flood resistance.
Check application banners:
Verify banner information with probes that exercise actual protocols.
Check listening ports:
The presence of certain ports might indicate the operating system and version.
Try to Telnet to the port and match the protocol to the port.
Look up the port number in the IANA listing.
Try standard clients.
Try connecting with additional protocols.
Check service behavior:
Look for remote protocols that may give up information about the host like Finger and SNMP.
Check remote operating system queries:
User sessions.
Last time user logged in.
Group information.
Sensitive data in file shares.
Available services.
Network interfaces.
Time of day.
Password policies.
Services with user account rights.
War dialing:
Identify telephone number blocks to dial.
Scan for dial-up systems.
Assess vulnerabilities for each system.
War driving:
Scan for wireless networks.
Assess vulnerability level of detected wireless networks.
Bluetooth attacks and threats:
Device detection.
Data theft.
Service theft.
Network sniffing.
Choose appropriate scanning technique:
Banner grabbing
Vulnerability exploiting
Inference testing
Network sniff replaying
Detecting patches
Consider the following when selecting a scanner:
Vulnerability checks
Scanner speed
Reliability and scalability
Check accuracy
Frequency of updates
Reporting capabilities
Start with safer checks and then move up to more risky scans later.
Use DoS scans with caution.
Test scanners first on test networks before pointing them at production networks.
Check for passwords from various sources:
Batch files and scripts.
Web pages.
Applications that save user passwords.
Service accounts that run with user rights.
Under keyboards or on sticky notes on the monitor.
Spreadsheets.
Text files.
Network services accepting clear-text passwords.
Temporary installation files.
SNMP community strings.
Password-protected files.
Use online password testing.
Use offline password testing:
Dictionary attacks.
Variant dictionary attacks.
Brute force attacks.
Password disclosure attacks:
Look for passwords lying around on the file system.
Look for encrypted passwords.
Sniff for passwords.
Use keystroke loggers.
Test for different DoS techniques:
Flooding
Resource starvation
Disruption of services
Look for stack overflows.
Look for heap overflows.
Look for format string overflows.
Look for integer overflows.
Try injecting overly long data into application input vectors.
Detect database servers on your network.
Scan database servers for missing patches.
Test access to database servers from both external and internal perspectives.
Check for database accounts with weak passwords.
Test whether data can be eavesdropped in transit to and from database servers.
Test applications that utilize database servers for SQL injection vectors by injecting invalid characters and reviewing code.
Try manual detection.
Review network architecture.
Watch for superfluous DNS queries.
Measure latency.
Use false MAC addresses and ICMP packet techniques.
Use trap accounts.
Use non-broadcast ARP packets.
Use automated detection tools.
Use Microsoft Network Monitor (NetMon) detection.
Check for IP spoofing vectors.
Look for applications that could facilitate spoofing such as insecure SMTP mail relays.
Check client, server, and protocol level for DNS spoofing vectors.
Determine all networks and network services that do not use a secure transport protocol such as IPSec and SSL.
Look for network application code that uses the INADDR_ANY (C/C++) or IPAddress.Any (C#) option, which could be susceptible to socket hijacking.
Inject invalid input into applications by lying about any session information.
Check for log flooding vectors.
Look for vulnerable logging mechanisms.
Look for unpatched IDSs and IPSs, and also signature databases that are out of date.
Test for canonicalization attacks.
Look for signs of intrusion such as the presence of rootkits, hidden files, and tampered log files.
Look for physical intrusion vectors.
Look for remote surveillance vectors:
Looking in windows
High-tech shoulder surfing
Electronic eavesdropping
Targeted equipment theft.
Dumpsters and recycling bins.
Lease returns, auctions, and equipment re-sales.
Test for social engineering attacks.
Check for client-level threats:
Look for XSS attacks in which Web output is dynamically generated.
Look for unpatched Web clients.
Check for server-level threats. Look for the following:
Repudiation vectors.
Information disclosure vectors.
Elevation of privileges vectors.
DoS vectors.
Check for Web service-level threats:
Unauthorized access.
Network sniffing.
Tampering.
Information disclosure.
Check for client-level threats:
Attaching malicious files
Exploiting unpatched e-mail clients
Embedding malicious content
Exploiting user trust
Check for server-level threats:
Attaching malicious files
Using mail relays to spoof messages
Exploiting unpatched e-mail gateways
Check for the following threats to domain controllers:
Password attacks
Elevation of privilege threats
Denial of service attacks
Physical security
Failure to use least privilege
Inadequate separation of different levels of asset
High-level internal users on extranet systems
High-level extranet accounts being used on systems you don’t control
High-level accounts logging onto different segments of the extranet
Systems dual-homed between the extranet and the internal network
Lack of intrusion detection systems
Being able to point out weaknesses in a network or system is very useful; however, the true measure of success of a penetration test is how it is used to improve the security of your organization. The following checklists are for countermeasures you can use to mitigate threats and weaknesses uncovered by your penetration tests.
Disclose only information about your organization that is backed up with a good business reason for doing so.
Don’t rely solely on obscurity. Layer it with other security mechanisms.
For registrar records, use role-based accounts. Listing telephone numbers outside corporate telephone blocks or using 1-800 numbers can help against war dialing attacks. Using post office boxes instead of real corporate addresses will help against dumpster diving attacks.
Include all hosts listed in your organization’s IP network block assignments in regular reviews.
Remove all nonpublic data on external servers such as Web servers.
Create and enforce policy regarding the type of content that is allowed to exist on publicly accessible servers.
Require nonpublic data to be removed from public caches.
Mitigate or eliminate any threats exposed by leaked information about your organization.
Create and enforce policy regarding which public discussion forums, if any, employees are allowed to participate in as well as what information is allowed to be discussed.
Allow only authorized secondary servers to perform zone transfers.
Block inbound traffic to TCP port 53 on perimeter firewalls to help prevent zone transfer information from leaving your network.
Disable reverse lookups.
Allow inbound traffic to TCP port 25 on perimeter firewalls to appropriate mail servers only. This is a common misconfiguration.
Do not mirror internal DNS information on external DNS servers.
Review the type of records you allow through DNS. Allow only the necessary records.
Enable IPSec.
Block any non-essential incoming ICMP packets such as ICMP redirects and echo requests.
When blocking UDP sweeps, remember to allow DNS to function.
Use router and firewall filters to block TCP sweeps.
Review the option of blocking outbound time-exceeded messages.
Use multiple layers of firewalls.
Use the principle of least privilege.
Employ host-level filters.
Use an IDS or other detection software to detect port scan attempts.
Expose services through reverse proxying.
Limit the type of packets that can reach your system.
Use an inline IDS or IPS system (or any other packet-scrubbing software) to normalize incoming traffic.
Assume the attacker already knows the exact operating system and version your systems are running, and take as many steps as possible to secure those systems.
Changing banner information can foil badly written attacker tools and low-skilled attackers.
Don’t expose unnecessary services.
Disable or filter unnecessary services, or use IPSec to secure communications.
War dialing:
Create policy.
Use strong passwords.
Keep systems and software up-to-date on patches.
Scan your network frequently for unauthorized or insecure dial-up systems.
Design networks securely.
Use communication devices with callback capabilities.
Disable or remove unnecessary modems.
War driving:
Create policy.
Scan your networks frequently for insecure wireless networks.
Educate users about the insecurities of wireless networks.
Use encrypted transport protocols.
Use SSID disabling, MAC filtering, and WEP cautiously.
Use the IEEE 802.1x standard.
Use WPA.
Bluetooth attacks and threats:
Turn discoverability of Bluetooth devices off.
Use built-in authentication and authorization mechanisms.
Keep device firmware up-to-date.
Disable Bluetooth functionality if not needed on devices.
Use long, difficult-to-guess passkeys that are changed often.
Don’t pair in public places.
Use encrypted links.
Educate users to use strong passwords and to avoid allowing applications to store their passwords.
Create policy that states scripts and batch files cannot contain passwords.
Search sources of Web pages for connection strings that might contain credentials.
Do not run services with elevated domain privileges, or try to secure them as well as possible.
Eliminate services on your network that take user credentials in clear text.
Use anti-spoofing filters for inbound and outbound traffic.
Keep systems up-to-date on patches.
Block directed broadcasts.
Blocking inbound ICMP might be useful in various situations.
Design secure code.
Perform regular code reviews.
Use built-in security features of your compiler such as /GS stack buffer overrun protection.
Write applications in managed code to reduce the threat of buffer overruns.
Use the SafeInt class to help avoid integer overflow attacks.
Regularly scan networks for unauthorized database servers.
Create policy that prohibits the installation of unauthorized database software.
Keep database servers up-to-date on patches.
Block external access to database servers. Restrict internal access to database servers to only those hosts requiring explicit access.
Use strong passwords for database accounts.
Check audit logs regularly for evidence of current or past brute force attacks.
Implement sniffing countermeasures to protect data in transit to and leaving from database servers.
To mitigate or eliminate SQL injection attacks, always validate input, use the principle of least privilege, avoid string concatenation, suppress error messages, and perform regular code reviews.
Myth #1: An attacker can remotely sniff networks.
Myth #2: Switches are immune to network sniffing threats.
Use manual techniques such as inspecting hub and switch link lights.
Use encryption to protect data during transport.
Secure core network devices.
Use switches correctly (see myth #2).
Use cross-over cables.
Secure hosts.
Create policy to prohibit the use of unauthorized sniffers.
Regularly scan for unauthorized sniffers.
Eliminate network and application protocols susceptible to spoofing.
IPSec can be used to eliminate network-based spoofing attacks.
Use ingress and egress filters at routers to validate network traffic.
Require outgoing e-mail to be authenticated.
Require users to digitally sign all e-mails.
Use anti-spoofing DNS rules.
Keep systems up-to-date on patches.
Use encrypted transport protocols to defeat network-based attacks.
Network applications should use the exclusive address use socket option when binding sockets.
Review application code, if possible.
Educate developers about session hijacking threats and attack-resistant code techniques.
Design secure applications.
Use digital signatures.
Do not allow log files to wrap.
Use log file scanning tools.
Keep logging mechanisms up-to-date on patches.
Keep IDS and IPS software and signature database up-to-date.
Normalize data before making security decisions to avoid canonicalization attacks.
Use cryptographic hashes to detect tampering.
Store log files on another server with strict ACLs.
To defeat XSS attacks:
Education developers.
Encode output.
Use built-in server or application protection.
Educate users.
Use built-in client protection.
Keep Web clients up-to-date on patches.
Keep Web servers up-to-date and configured securely.
Use the URLScan and Microsoft Internet Information Services (IIS) Lockdown tools for IIS installations.
Use authentication to protect Web services.
Use encrypted transports for communications.
Use digital signatures to verify validity of service communications.
Suppress disclosing detailed error information from Web errors.
Client-level:
Educate users.
Enable e-mail client protection.
Install antivirus software.
Create policy.
Digitally sign e-mails.
Keep e-mail clients up-to-date on patches.
Server-level:
Install antivirus software.
Require authentication to access third-party relays.
Keep servers up-to-date on patches.
Spam:
Educate users about spam e-mails.
Use e-mail client protection.
Disable services that could be used to propagate spam.
Use secondary e-mails.
Use spam filters at mail gateways.
Keep spam filters up-to-date on patches and filter technologies.
Protect domain accounts by using strong passwords.
Disable LM hashes.
Disable reversible encryption.
Force strong passwords across domains.
Educate users and administrators about strong passwords.
Use Syskey protection.
Disable any non-essential services.
Keep domain controllers up-to-date on patches.
Protect highly privileged domain accounts and groups.
Use multiple domain controllers.
Back up regularly.
Create policy for physical access.
Keep detailed log of access to domain controllers.
Limit access to domain controllers.
Store domain controllers in physically secure locations.
Use least privilege.
Separate networks of different levels of trust and asset value.
Limit or eliminate internal user accounts on extranet systems.
Avoid using high-level extranet accounts on systems you don’t control.
Avoid using high-level accounts to log onto different segments of the extranet.
Protect or eliminate any unauthorized dual-homed hosts between the extranet and the internal network.
Use IDSs to detect attacks.