Scans

A scan detects and identifies network and host vulnerabilities in your environment. Scans can perform external attack simulations as well as comprehensive vulnerability checks including registry evaluation. Alert Logic scans can also help you meet PCI compliance requirements through Fortra VM.

This topic describes the types of scans that are supported, best practices for running successful scans, and how to configure and manage scan definitions and results.

Scan types

The following table describes the types of supported scans:

Scan Type	Description
internal	An internal scan runs from an Alert Logic appliance in your environment. When you define a scan, you can specify credentials to use with the internal scan. If you provide credentials, Threat Manager can log on to each host on your network and collect information about the host while it performs comprehensive vulnerability checks including registry setting evaluation. If you do not provide credentials, Threat Manager scans your network without logging on to each host and performs as many checks as possible.
external	An external scan runs from the Alert Logic data centers against your environment. This type of scan simulates attacks from outside your network and identifies potential issues from these attack types.
PCI (through Fortra VM)	A PCI scan is a special type of external scan that is used specifically for Payment Card Industry (PCI) compliance requirements. Alert Logic customers can use the self-service PCI Approved Scanning Vendor (ASV) capabilities in Fortra VM.

Scanning best practices

When configuring your scans, use the following guidelines to create successful scans and scan results.

Request authorization before scanning cloud-based assets

AWS

Alert Logic performs vulnerability scans, not penetration testing. AWS treats scanning the same as penetration testing, requiring scan clients to fill out and submit a penetration testing request form. This authorization allows AWS to differentiate between testing and a real attack on their systems.

The process and form for requesting authorization from AWS are located here.

Azure

While Azure does not require pre-approval for scanning, clients must comply with their terms and are encouraged to fill out and submit a penetration testing notification form.

The terms and notification form from Microsoft are located here.

Be smart when scheduling scans

Schedule your scans to be both effective and efficient.

• Scan your servers, firewalls, and routers during off-peak times. To effectively balance scanning resources across your enterprise, configure scanning of data center assets to occur during off-peak times.
• Do not scan during service windows. Service windows are the times when you do backups, hardware maintenance, or apply patches. Valid scan results require that the server is powered on and not in the middle of a reboot. For best results, scan after you apply patches and not while applying patches.
• Scan your workstations during working hours. At night, laptops go home and workstations get powered off. Scan laptops and workstations when they are available on your network.
• Scan new computers before use. Scan new servers before you plug in to the Internet. Time to infection for an unpatched, unprotected server can be less than an hour.
• Scan often. Security is a moving target that you cannot hit in three month scan intervals. Establish a reasonable schedule that scans as frequently as possible and can be adhered to.

Make sure your scans have time to complete

An incomplete scan yields incomplete results. If your scans cannot finish, you may have undetected vulnerabilities. To get a comprehensive vulnerability assessment, it is imperative that all scans—no matter how lengthy—run to completion. You can affect your scanning throughput by either modifying scan definitions or by increasing scanning capability, as follows:

• Open your scan window. Because of improvements in scanning technologies, you do not necessarily need to limit your scanning activities to narrow time frames during off-peak hours. It is generally safe to let your scan run during normal business hours without impact to performance or availability of assets. Many customers run their scans continuously.
• Run open-ended scans. When scheduling your scan, consider leaving the scan end time blank.
• Split up long scans. Rather than a single, comprehensive scan, use multiple scans. Set several smaller scopes and spread the load across multiple scanners.
• Run scanners in parallel. If you have multiple appliances, you can run scans in parallel. Running scans in parallel requires spreading scans across multiple appliances.

If scans are taking an unusually long time to complete, there may be other local factors involved. Factors include:

• Back-end database speed
• Network connection or infrastructure issues
• Number of simultaneous connections by the scanner
• Number of vulnerability checks
• Client computer/server performance and response time

Know what to scan

Consider what to scan and how often to scan it. Your scanning strategy might require multiple scan definitions with different schedules and frequencies.

• Scan common ports often, and all ports less often. Use the following recommendations:
  • Scan common TCP and UDP ports often, at least once a week. Almost all new vulnerabilities appear on common TCP and UDP ports.
  • Use authenticated scanning on common ports. This is the best way to lower scan times, reduce false positives, and detect the latest vulnerabilities.

  • Scan all ports infrequently. Scanning all TCP ports and all UDP ports is time-consuming and has minimal benefit over scanning common TCP and common UDP ports.

    As a general best practice, on external systems, disable all UDP ports at the host level, the firewall level, and the router level. Unless you have a specific reason, do not have open UDP ports on your internet-facing systems.

  • Scan frequency recommendations:

    Scan frequency	Common TCP and UDP ports		Typically Vulnerable TCP and UDP ports		All TCP and UDP ports
    	Internal scan	External scan	Internal scan	External scan	Internal scan	External scan
    Daily		x
    Weekly	x			x
    Monthly			x			x
    Quarterly					x
    After configuration change					x	x
    Suspicion of break or infection					x	x

• Do not scan "all ports open" configurations commonly found on firewalls. To improve security posture, some users implement firewall or router configurations that are designed to slow scans. These configurations are designed specifically to slow down an attacker but will slow down your scans as well. Scanning targets with these types of configurations should not be done as part of regular scanning, but should be scanned individually using an outside vendor tool to assess the effectiveness of the protection mechanism. If you decide to use this protection mechanism, ensure that Alert Logic appliances and external scanners are whitelisted and not affected by the protection mechanism.
• Configure personal firewalls to allow access by scanner. Where personal firewalls are used for desktops or workstations, credential-based scans are not possible without configuration setting changes. Configure Windows firewalls to allow scanner access on Windows Management Instrumentation (WMI), configure your Linux box to allow access via SSH, and then run a credentialed scan.
• Define reasonable, non-overlapping scopes.
  • Scan a range of 256–1024 IP addresses at a time. Scanning large IP address ranges (for example, 10.0.0.0/9) will send large amounts of unnecessary traffic to your network which might cause the scan to fail.
  • Avoid configuring multiple scans that overlap IP address ranges. This creates redundant results and extends scan times.
  • Scan DMZ, internal servers, and workstations separately, as they will likely need different levels of attention. Also, consider limiting scope by role (for example, database, web, application, QA, test, development, production).

Optimize your scans

When setting up your scans, consider your strategy. Develop an implementation that is particular to your scanning targets and environment.

• Establish your initial scan window. The time required to complete a scan is greatly dependent on the types of scans you run as well as environmental factors like hosts and bandwidth. If you must set an end time and want to determine the scan window requirements, run a one-off scan without an end time to establish the initial duration, and then add 20-30 percent more time to accommodate future growth. If the scan takes longer than you want, consider reducing scan scope and spreading scans across multiple appliances to reduce time.
• Be mindful of what you are scanning. In terms of length, not all types of scans are equal. Windows-credentialed scanning takes longer than all other credentialed or non-credentialed scans. Under test scenarios, Windows-credentialed scans have taken up to four times as long as other scans. The web application scanning component used in Alert Logic PCI scans can also run long due to the amount of web pages present and the number of fields on each page, multiplied by the number of sites being scanned. Consider these factors when defining your scans and determining scan windows.
• Multitask. Scan your servers and workstations separately in a staggered schedule to allow remediation in stages. For example, you can perform remediation on servers while scans on workstations continue to run.
• Try not to scan over WAN links or VPN. The traffic between the scanner and the scan target is high compared to the relatively low traffic between the scanner and Alert Logic. Place the scanner on the same side of the VPN or WAN link as the scan target for the best use of your bandwidth.
• Use un-credentialed scans as fallback. Credentialed scans produce the most accurate results and should be used on all servers and workstations. Un-credentialed scans should be used only for devices where credentialed scanning is not available, for example, routers, switches, and printers.

Originating IP addresses for scanning

The following table contains the broad range of IP addresses owned by Alert Logic for existing and future use. Alert Logic scanning technologies use a specific subset of these IP addresses for scan origination. Make sure that your active protective mechanisms, such as IDS, IPS, WAFs, and firewalls that can send shun/block requests, to allow scanning traffic from all of the following IP addresses.

IP/CIDR	# of addresses	Included addresses
204.110.218.0/23	512	204.110.218.0 — 204.110.219.255
208.71.208.0/22	1024	208.71.208.0 — 208.71.211.255
185.54.124.0/22	1024	185.54.124.0 — 185.54.127.255

Access Alert Logic scans

You can access most scan-related features from the Scans page in the Alert Logic console. These features include creating and scheduling scans, managing scan results, and processing steps for PCI compliance.

To access scans and scan results:

1. In the Alert Logic console, click OVERVIEW, and then click Scans.
2. On the Scans page, use the tabs to access scan features, as follows:
   • Statistics: Access summarized vulnerability information for your environment from overall scan results. See View vulnerability statistics.
   • Scans: Create and update scan definitions and access scan results.
   • PCI Compliance: View historical PCI scan results. See Manage PCI scans.
   • Search: Search scan results for criteria such as vulnerability name and risk levels. See Search scan results.

Manage scans

You can access detailed information about network and host vulnerabilities discovered during internal and external scans from the Scans tab on the Scans page in the Alert Logic console. From the Scans tab, you can create new scans, edit existing scan definitions, and view scan results.

View scans

From the Scans tab on the Scans page, you can view scheduled vulnerability scans, scan status and results, and links to disable, enable, and delete the scans.

To view vulnerability scans:

1. On the Scans page, click the Scans tab.
2. If you manage more than one customer, in the Customer drop-down list, select the customer, and then click Go.
   Scheduled scans, scan status and results, and links to disable, enable, and delete the scans are displayed.
3. (Optional) To change the definition of a scan, see Modify scan definition.
4. (Optional) To change the status of a scan, see Modify scan status.

Define a scan

You can define and schedule scans to run on a regular basis to help you identify vulnerabilities across your organization. From the Scans tab, you can define and schedule internal and external scans.

Create a new scan

1. On the Scans page, click the Scans tab.
2. If you have access to more than one entity, use the drop down menu to select the entity you want to scan.
3. Click Schedule New Scan.
4. Fill in the information according to the instructions below.
5. Click Submit scan job.

Scan Details

1. In Scan Title, type a descriptive name for the scan.
2. In the Type of Scan drop-down list, select one of the following options:
   • Internal Scan: This scan originates inside your network, behind your firewall, and shows an insider threat perspective.
   • External Scan: This scan originates from Alert Logic, outside your network, and shows an outside threat perspective.
3. If you chose Internal Scan, choose Appliances for your scan. The Unavailable Appliances box lists all appliances that are offline or deactivated. If you chose External Scan, the Appliances option is not available.
4. Under How to Scan, choose one of the following options:
   • Full Scan is a complete scan on all in-scope devices.
   • Uphost only scan is a scan that detects only the alive/offline status of each host.

What to Scan

Choose whether to scan by Zones, Host Groups, or Individual IPs, and then choose the appropriate item(s) from the list that appears.

• Zones are created around Alert Logic appliances. Set up zones on the Management page.
  • Choose one or more zones from the list. Press and hold the Ctrl key to select multiple items. To select adjacent items, click the first item, press and hold the Shift key, and then click the last item.
• Host Groups are sets of one or more hosts. Multiple host groups may reside within a single zone. Set up host groups on the Management page.
  • Choose one or more host groups from the list. Press and hold the Ctrl key to select multiple items. To select adjacent items, click the first item, press and hold the Shift key, and then click the last item.
• Individual IPs allow you to select the specific IPs to scan.
  • You may enter addresses, subnets, or address ranges. When you are done typing the information, click Add the above hosts to the scan to add them to the list. You may add more hosts or remove them from the list.

Scan Credentials

Enter user credential information to ensure the scanner has access to all necessary parts of your network. Alert Logic recommends adding user credentials for the most accurate scan. The prompt accepts information for Windows Credentials, SSH Credentials, and SNMP Community Names. For more information on authenticated scanning, click here.

Schedule Options

Set the timing of the scan. You may choose to scan once or set a recurring scan that runs quarterly, weekly, or on specific days of the month.

To set scan schedule:

1. Set the scan frequency. Choose from the following options:

   • Quarterly: Set the timing of the scans within the quarter:
     • Choose the first, second, or third month of the quarter in the Run scan in: drop down menu.
     • Set the day of the month in the on this day: text box.
   • Every Week:Set the day of the week for the scan to run.

   • Specific Days of the Month: Type in the date(s) you want the scan to run each month.

     If you want your scan to run later in the month, you should set it for the 28th at the latest. If you set it for the 31st, you will miss February and the months that have only 30 days.

   • Specific Weekday of the Month

     Use the drop down menus to choose the day you want the scan to run each month. For example, you may set it to the second Wednesday every month.

   • One Time

     Enter a date to run a single scan.

   • As soon as possible

     This option puts the scan in the queue so that it runs as soon as possible.

2. In the Run scan from: box, set a time for the scan to begin. This option is not available if you chose to run the scan as soon as possible.
3. In the Time Zone drop down menu, select a time zone. This option is not available if you chose to run the scan as soon as possible.

Advanced Settings

Click Advanced Settings for more options, if necessary:

• For Scan end time (optional):, set a time for the scan to end. Alert Logic recommends leaving this option empty because it may abort your scan before it is finished.

• Check the box to Enable roll-over scanning.

  Alert Logic discourages using roll-over scanning, as the feature is deprecated.

• If necessary, enter specific IPs in IP Addresses to Exclude.
  • You may enter addresses, subnets, or address ranges. When you are done typing the information, click Add the above hosts to scan to add them to the list. You may add more hosts or remove them from the list.

  • Alert Logic discourages excluding items from your scans.

Scan Report

Check the box to have Alert Logic send an email containing the scan results after the scan completes. Choose email contacts from the list, and add as many as you want.

Modify scan definition

After you have created a scan, you can modify its definition. For example, you can change what IP addresses are scanned, when the scan is scheduled to run, or the credentials used to log in to host computers.

To modify a scan definition:

1. On the Scans page, click the Scans tab.
2. If you manage more than one customer, in the Customer drop-down list, select the customer, and then click Go.
3. In the displayed list of scans, click the Scan Title of the scan to modify.
4. On the Edit Scan page, modify the scan definition, and then click Save.

Modify scan status

Each defined scan has a status, which is displayed in the list of scans. Scheduled scans that are enabled show a status value of a date (for example, Sep 8 2016 10:00pm), which is when the scan is scheduled to run next. Additional status values include scanning, suspended, and disabled.

You can modify the state of a scheduled scan if needed. For example, to minimize potential risk when you make changes to your network, such as the roll-out of a new version of software on your mission critical servers or devices, you may want to deactivate a scan. The scan remains disabled until you enable it again.

You can also suspend or resume a scan that is in progress, or delete a scan entirely.

To modify scan status:

1. On the Scans page, click the Scans tab.
2. If you manage more than one customer, in the Customer drop-down list, select the customer, and then click Go.
3. Perform one of the following actions in the row of the scan to modify:
   • To disable a scheduled scan, click Disable.
   • To suspend a scan in progress, click Suspend.
   • To resume a suspended scan, click Resume.
   • To cancel a suspended scan, click Cancel.
   • To delete a scheduled scan, click Delete.

Manage scan results

Through the Scans feature, you can access valuable vulnerability information about your network through your scan results. You can view high-level trend information as well as granular details. Reviewing the details of scan results helps to identify issues you can address to improve your security posture.

View vulnerability statistics

Several types of trend views are provided to help you better understand your recent activity at a high level.

To view vulnerability statistics:

1. On the Scans page, click the Statistics tab.
2. Select one of the following views to display:
   • Most Vulnerable Hosts
   • Most Vulnerable Host Groups
   • Most Vulnerable Zones
   • Vulnerability History
   • Vulnerabilities by Risk Level

View results by scan

You can easily view the results for each scan execution. From the results, you can view details about any vulnerabilities that are found. You can also export scan results in PDF or .csv format for download.

To view results by scan:

1. On the Scans page, click the Scans tab.
2. If you manage more than one customer, in the Customer drop-down list, select the customer, and then click Go.
3. A list of scans appears, in alphabetical order by title. For each scan, you can perform the following actions:
   • Enable: Set the scan to run on a set schedule.
   • Delete: Delete the scan results from the system.
4. Click the link in the Results column to expand the results for the scan. For each Scanned Date row, you can perform the following actions:
• In the Results column, click the linked number of hosts to open a list of hosts and the vulnerabilities for each. Click PCI Scan Results to see the PCI scan page.

• Click the icons in the Export column to download reports in various formats.

  • Click the green CSV icon () to download a .csv file with vulnerability and exposure details.
  • Click the blue CSV icon () to download a .csv file with host details.
    

  The industry-standard CSV downloads include detailed host and vulnerability information. The format allows you to analyze, sort, and filter the information externally in the software of your choice. Alert Logic recommends the use of the CSV downloads for all scan analysis.

• Click Delete to delete the scan results. This deletes results from the selected date only.

Search scan results

You can search all saved scan results for specific vulnerabilities by name or ID, risk level, zone, and host group. You can also filter your search results by all, active, or inactive vulnerabilities. This feature is useful if you discover a vulnerability and want confirmation, or if you discover a security breach and want to discover the vulnerabilities of a host.

To search scan results:

1. On the Scans page, click the Search tab.
2. If you manage more than one customer, in the Customer drop-down list, select the customer, and then click Go.
3. Enter and select the appropriate options, and then click Search.

Ignore a vulnerability

If you cannot resolve a vulnerability immediately, you can temporarily deactivate the vulnerability. When you deactivate a vulnerability, the Alert Logic console does not remove the vulnerability from reports. You can deactivate vulnerabilities for a specific host or for all hosts.

To ignore a vulnerability:

1. On the Scans page, click the Scans tab.
2. If you manage more than one customer, in the Customer drop-down list, select the customer, and then click Go.
3. Next to the scan that identifies the vulnerability to deactivate, click and expand Results.
4. Under the Results column, next to the date the scan was run, click the hosts link.
5. In the Hosts window, under the appropriate host, click the name of the vulnerability.
6. Check one or more vulnerabilities you want to deactivate.
7. On the bottom right, click Change Status.
8. Select one of the following options:
   • This Host—Deactivates this vulnerability on this host only.
   • All Hosts—Deactivates this vulnerability on all hosts. With this option, you must provide a global descriptive note.
9. Select Inactive.
10. Click Save.

Report a false positive

Sometimes vulnerability scans identify a vulnerability in your environment that may be a false positive. To investigate an identified vulnerability that may be a false positive, contact Alert Logic. The security analysts in the Alert Logic Security Operations Center (SOC) carefully review the vulnerability and assess the accuracy of the result.

To report a false positive (for non-PCI scans):

1. From the heading of the report that contains the vulnerability in question, find the date the report ran and the Report ID.
2. Contact Alert Logic using one of the following options:
   • Contact Alert Logic Support at (US) (877) 484-8383 or (EU) +44 (0) 203 011 5533.
   • Send an email to support@alertlogic.com.

If the security analyst determines the vulnerability is a false positive, the security analyst updates the vulnerability in the system database.

Clean up scan results

As part of your maintenance activities, you can "clean up" scan results. When you clean up scan results, certain results are hidden in the Alert Logic console, providing you with a cleaner view. You can clean up results predating a specific date, or you can clean up results for individual scans. The hidden results remain in the system and are included in your reports.

Clean up scan results by date

You can hide older scan results from the Alert Logic console by specifying a date and time; results with a Scanned Date that is older than the specified date are hidden.

To clean up scan results by date:

1. On the Scans page, click the Scans tab.
2. If you manage more than one customer, select the customer in the Customer list, and then click Go.
3. Click Clean up Scan Results.
4. In the Clean up Scan Results dialog box, enter the date and time before which to hide scan results, specify whether to also hide inactive scans, and then click Clean up.

Clean up scan results by individual scans

You can hide individual scan results from the scan list.

To clean up scan results by individual scans:

1. On the Scans page, select the Scans tab.
2. If you manage more than one customer, in the Customer drop-down list, select the customer, and then click Go.
3. In the row of the scan for which to hide results, click Results.
   A list of scan executions appears, ordered by scan date.
4. For each Scanned Date row, click Delete to hide the results of that particular scan.

Manage PCI scans

c

Technical Description

Port scan

The port scanning segment of the scanning process is split into two parts: the TCP port scan and the UDP port scan. Alert Logic uses full connect scans on both types of ports.

TCP port scan

1. The scanner makes a connection to the target server through each port in the scan policy.
2. The scanner executes a full RFC compliant TCP/IP handshake
3. Each port gives one of three responses:
   • Port open: These ports get examined further in the next step of the scanning process.
   • Port closed: These ports are ignored for the remainder of the scan.
   • No answer or dropped package: These ports are filtered out because the Alert Logic request can not get through. The time out period on these ports is ten seconds.

UDP port scan

1. The scanner attempts to make a connection to the target server through each port in the scan policy.
2. The scanner waits the maximum amount of time for each port.

3. The scanner labels each port as open or filtered.

   UDP ports do not always send responses even if they are open, so the scanner sometimes labels open ports as filtered.

Service detection

After the port scan finds open ports, the service detection segment of the scan identifies which services are running on the port. The scanner searches all open ports for all known services, in case services are running on non-standard ports.

1. The scanner sends traffic to ports using various protocols and records those that get responses.
   • TCP ports: The scanner sends specific queries to the port until it receives a recognizable response.
   • UDP ports: Because UDP ports without connection errors are inferred to be open, UDP service detection is both slow and unreliable. Many systems filter out ICMP error messages, or only send a certain number of error messages per second.
2. The scanner analyzes each response received and determines which type of service sent the response.

Version detection

The version detection segment of the scan attempts to identify the following items for the port:

• Version numbers for each service on the port
• Applications running on the service
• Third-party plug-ins
• Security patches

This phase of the scan is done in two steps:

1. The scanner runs the Nmap service and version detection.
2. The scanner runs proprietary Alert Logic service and version detection.

Results from the two steps are then combined together into a comprehensive list of software, versions, and patches.

Vulnerability evaluation

In the vulnerability evaluation phase, Alert Logic compares the software/version/patch list to its vulnerability database. The database includes over 70,000 vulnerable versions and their associated vulnerabilities. The scanner matches the software list with the vulnerability database and provides clients with a list of vulnerabilities that may be present in their environments.

Assessment scope

Following is a sample list of services, devices, and operating systems that Alert Logic tests:

Operating systems

• Linux
• Microsoft® Windows®

Web servers

• Apache
• Microsoft® IIS

Web application servers

• Apache Jakarta Tomcat
• JBOSS

Common web script

• Commonly found scripts (typically, common gateway interface [CGI] scripts) written in various languages
• Ecommerce related scripts, such as shopping carts and CRM scripts
• ASP
• PHP

Database servers

• Microsoft SQL Server™
• MySQL®
• Oracle®
• PostreSQL

Mail servers

• Microsoft® Exchange
• SendMail™

Firewalls

• Cisco PIX®
• NetScreen

Routers

• Cisco

Common services

• Domain name system (DNS)
• file transfer protocol (FTP)
• simple mail transfer protocol (SMTP)

Router check

The scanning solution tests the router for known vulnerabilities and configuration issues in the firmware.

Firewall check

• Check for up-to-date patches on known vulnerabilities
• Check for open ports indicating inadequate configuration

Operating system check

Vendors release patches to address new exploits and flaws. The scanning solution verifies that the operating system has the latest patches installed.

Database check

New exploits are found regularly for database products. The scanning solution detects exploits and open access to databases.

Web server check

The scanning solution tests for all known vulnerabilities, exploits, and configuration issues on web servers. New exploits are routinely discovered in web server products. The scanning solution detects and reports known exploits. The scanning solution checks for other best practices, for example, making sure that directory browsing is not possible on the server.

Complex passwords

Alert Logic supports complex passwords; however, some special characters give command line interfaces difficulty, as they have special meanings. Keep your password special characters limited to numbers (0-9), periods (.), colons (:), semi-colons (;), quotes (',',","), percentages (%), and spaces ( ).

Scanning depth

Alert Logic scanning enables safe and accurate assessments without affecting network operations. If the system finds an open SNMP service, it will poll it for as much information as possible (true operating system, real hostname, patch level), but it will not attempt to exploit holes to demonstrate what an attacker can do.

Backporting

Backporting involves taking a software patch and applying it to an older version of the software than the version it was designed to modify. Backporting is specific to some UNIX/Linux and open source vendors. See also Red Hat about backporting security fixes.

If you are using zero privileged level of network scanning, then Alert Logic scanning provides the option to ignore a vulnerability, which documents the presence of your vendor-supplied patch and suppresses further reporting of this issue on those IP addresses. You can export the list of ignored vulnerabilities as a report to give to other auditors showing the documented fixes for supposed network vulnerabilities. Network scanners report based on the found version, and auditors expect all vulnerabilities to be enumerated and exceptions to be documented.

The best way to handle backported patches is to do credentialed scans. The preferred method for handling this is using the OVAL algorithm and data feeds Alert Logic gets directly from RedHat and other Linux vendors. When you run scans with credentials, the system automatically enumerates the list of installed patches and auto-suppresses vulnerabilities that have been addressed by backported patches. Alert Logic scanning can do this internally and externally from the internet, but it requires standard user access to a Secure Shell (SSH) service on that computer.

When a network vulnerability scanner assesses a computer, it bases some of its findings on found versions of software. If these versions are known to be vulnerable to certain issues, they are enumerated as vulnerable to their respective CVEs. If your vendor backports security fixes and does not update the software version number, you may not be vulnerable despite what the Alert Logic vulnerability report states.

Scanning system details

SSL certificate host name discrepancy

This vulnerability appears in a report when the name listed in the SSL certificate configuration does not match the name used to access the host. This is an automatic failure for external PCI assessment scans due to the inability to verify the legitimacy of the host.

This vulnerability commonly appears when an administrator reuses an SSL certificate from one web application for another. For example, an SSL certificate created for www.mydomain.com can not be used for mypage.mydomain.com.

Mitigation

Use the mitigation methods listed below to address this vulnerability.

• External sites
  • Purchase a new SSL certificate created specifically for your web application.
  • Use a wildcard SSL certificate for any page on the domain.
• Internal methods
  • Update the reverse DNS record of the IP address to be the same as the subject of the SSL certificate. The scan will automatically detect the reverse DNS name and if it matches the subject of the SSL certificate, the issue will not be flagged.
  • Update the SSL Certificate subject line to match the host name of the device.
• Other methods
  • If the scanner was unable to resolve a host name for the host, it is typically related to the configured DNS servers not having a record of the host.
  • If the certificate is not valid because it is a generic or default self-signed certificate, you can choose to filter the vulnerability at the IP or job level. If the host name (or lack thereof) provided by the certificate does not match the host name discovered during scanning, this is a valid finding. Filtering this vulnerability is at the discretion of the client only.

False positives

False positive in external or internal scan

If the scan result is a false positive, you can make the exposure inactive to remove the results from reports.

False positive in PCI scan

In many cases, the SSL certificate host name discrepancy appears because the host was scanned via IP address instead of via fully qualified domain names (FQDN). PCI-DSS requires customers to supply FQDNs in addition to providing all external-facing IP addresses and all other unique entryways into applications for the entire in-scope infrastructure. This information must be included when you schedule a scan.

If you deploy load balancers, the scan may only see part of the configuration behind the load balancer. In these cases, the following applies:

• Localized load balancers: You must supply documentation showing that the infrastructure behind the load balancer(s) is synchronized in terms of configuration.
• External load balancing services: Implement a configuration to ensure that all IP addresses and ranges provided are successfully scanned.

If you believe that a PCI assessment failure was in error, first verify that the FQDN resolves to the host using an outside source such as www.sslshopper.com or www.digicert.com/help. These sources may also identify other certificate problems.

PCI scan disputes

If the FQDN resolves to the host, you may submit a dispute. Provide the FQDN in the dispute comment so that Alert Logic can validate the certificate. Enter only one FQDN per host. A single dispute comment containing a blanket statement for all hosts found in the scan is not acceptable. In the case of a load balancer, provide all expected IP resolutions of the FQDN and confirm that hosts behind the load balancer are in sync.

In general, using the FQDN in the scan configuration prevents this vulnerability from appearing.

Brute force user name and password guessing

Alert Logic scanning performs some user name and password guessing; however, it does not perform an all-out brute force attempt against accounts. Many devices come with default administrative account names, and the system checks for standard user name/password combinations, such as:

• 3Com hubs/switches default logon—manager:manager
• Windows Network—administrator:administrator or administrator:blank
• MS-SQL—sa:blank

Denial-of-service attacks and buffer overflows

Alert Logic does not run any test that can cause significant or fatal damage to a system or application. Alert Logic can test some buffer overflow and denial-of-service (DoS) vulnerabilities without harming your server or service. Strict quality assurance measures ensure tests are safe before release. It is impossible to test for all configuration possibilities and it is difficult to completely rule out any disruptions.

For vulnerabilities that require a non-active testing method, the Alert Logic scanning system deploys a passive scan operation utilizing versioning, configuration testing, and inference to determine the likelihood of the existence of a given vulnerability. Vulnerabilities that cannot be completely verified are stated as warnings, with associated detail to evaluate mitigation strategies for that issue.

Denial-of-service situations

Alert Logic has identified two scenarios in which active testing could cause a DoS situation on a network.

• Consumption of firewall connections/exhaustion of firewall resources
  If an internal Threat Manager appliance is placed behind a firewall and instructed to scan computers on the other side of the firewall, the appliance could exhaust the available outbound connections/resources of the firewall. This has happened on Cisco PIX firewalls where port address translation (PAT) was used to PAT private, internal addresses to the outside interface. During the port scanning phase of the scan, a large number of connections are initiated to identify all open ports on a target device.
  To avoid this scenario:
  1. Place the appliance on a segment of the network where it does not have to go through the firewall to reach the target.
  2. Provide a static IP translation for the IP address of the testing unit. This reduces the number of connections the firewall must "remember" during testing.
• Debug level logging/religious logging
  An appliance performing a high level of logging can cause a DoS situation. This has happened in both internal and external testing. This scenario is a classic security vulnerability. If a firewall logs every connection attempt to a remote system, it could generate gigabytes of log file traffic, which causes a strain on network infrastructure and exhausts file system resources of the remote logging console. This is a known problem with debug-level logging (i.e., logging everything). When a port scan is performed, the number of connections to a device can range from 1,500/3,000 ports connection attempts up to 65,535/131,070 ports connection attempts. To prevent a DoS situation, use a lower level of logging.

Scans and network performance

The Alert Logic scan engine includes the following features designed to protect network performance:

• Active scan tools designed and tested to be sensitive to network operations
• Passive asset profiling that does not require an active test
• Scan job configuration options
• Schedule configuration options
• Bandwidth limits on scan jobs
• Custom parameters for more light or heavy port scanning
• Option to exclude IP addresses for devices that may not respond well to scanning
• Flexible scheduling to ensure scan activity occurs only during approved times

Load-balancing devices

If your environment has a web farm behind a load-balancing device, there is no way to asses all devices, because the load-balancing device creates the algorithm that determines load distribution. The Alert Logic software would find issues in your code base, but computer-specific issues might be missed due to the decisions made by the load-balancing device.

To ensure that Alert Logic scans each device, place a Threat Manager appliance where it reaches the individual computers in the web farm.

Operating systems

Alert Logic scanning generally tests for any operating system that supports a TCP/IP stack; however, results vary among operating systems. DOS and Windows 3.1 WFWG support TCP/IP, but few known vulnerabilities exist for these systems.

Alert Logic does not rely on operating system guessing as a part of vulnerability assessments. For instance, a network that uses an F5 BIG-IP load balancer on its perimeter would skew the results of a test that relied on operating system guessing. While the web site being hosted could reside on a Microsoft IIS server, the BIG-IP itself fingerprints as a BSD UNIX operating system. In this case, a more comprehensive test prevents inaccurate and possibly dangerous results.

Operating system and host name reporting

Operating system guessing and host name determination in Alert Logic scanning is based off of a weighted system. The report shows the item with the highest weight (confidence factor).

Examples of the host name weighted system are as follows:

Method	Weight
DNS forward lookup	1
FTP/SMTP/Telnet/IMAP/POP3 Banners	4
SSL Certificate Subject Names	5
MS RPC	5
SNMP	6
MSSQL	8
NetBIOS – nbtstat	12
Authenticated SSH	13
Authenticated NetBIOS	15

Examples of the host weighted system are as follows:

Operating system guessing method	Weight
IP Fingerprinting (nmap)	2
HTTP Server Headers	5
FTP/SMTP/Telnet/IMAP/POP3 Banners	6
NetBIOS – nbtstat	8
Authenticated – SNMP	10
Authenticated – SSH	11
Authenticated – NetBIOS	15

Authenticated scanning

Alert Logic allows you to use credentials to perform host-level authenticated scanning. Using Windows or SSH credentials as part of your scans allows for more accurate vulnerability scans and lowers the number of false positive results.

This section provides information on:

• Windows authenticated scanning
• UNIX/Linux authenticated scanning
• Amazon Web Services authenticated scanning
• Credential storage

Windows authenticated scanning

Windows authenticated scanning is an authenticated network-based method for interrogating the target machine for missing security-related patches and updates.

To run Windows authenticated scanning, you must set up the following parameters:

• Credentials— Alert Logic scanning needs a local or domain administrator account to accurately assess the patch level of your computers.
• Network access to RPC/WMI, NetBIOS and SMB/CIFS ports— Alert Logic scanning requires access to RPC/WMI (135/tcp, 49152-65535/tcp), NetBIOS (139/tcp, 137/udp, 138/udp) and SMB/CIFS (445/tcp and 445/udp). Network or personal firewalls blocking access to any of these protocols will prevent access to Windows patch scanning.
• Enable Remote Registry servicesThe Remote Registry service must be enabled and started. Verify this from the Administrative Control Panel under Services.

If the authentication fails, the scan report will list Exposure ID: 16205 - Local Checks Error.

To set up a dedicated user for scanning:

Use the following procedure to set up a dedicated user that Alert Logic can use for authenticated scanning.

1. Click Start, type lusrmgr.msc, and press Enter.
2. Right-click the Users folder, and then click New User.
   
3. On the New User window:
   1. In User Name, type a new user name (for example, Alert Logic Dedicated Scanning User).
   2. In Password, type a password.
   3. In Confirm Password, type the password again.
   4. Click Create.
      
4. After the window refreshes, indicating successful user creation, click Close.
5. Click the Groups folder, then right-click Administrators and click Add to Group.
   
6. On the Administrators Properties window, click Add.
   
7. On the Select Users window, in Enter the object names to select, type the newly created user (for example, Alert Logic), and click Check Names.
   
8. After the window refreshes, reflecting any changes and user confirmation, click OK.
   
9. On the Administrators Properties window, confirm that the user appears under Members, and click OK.
   
10. Close lusrmgr.

To set up WMI:

The Alert Logic scanner needs to connect to Windows Management Instrumentation (WMI) on the machine, in addition to remote registry, to pull version information from .dll and .exe files, as well as information stored within Windows Management services and settings. Unlike Unix and Linux, which come with SSH secure remote access where the system can log on and interrogate things as a user, Alert Logic scanning requires the administrative privileges due to the limitations of methods available to remotely access Windows machines. Alert Logic scanning does not make registry changes and does not write to the machine. To learn more about registry keys, refer to the Microsoft documentation here.

The Open Vulnerability and Assessment Language (OVAL®) method is the preferred method of network-based patch scanning. The scanner uses the OVAL method for assessing Windows-based machines for a variety of Microsoft-specific and third-party application security patches.

WMI comes installed on all Microsoft operating systems. The following procedure describes how to enable remote access to WMI.

To enable remote WMI requests:

1. On the target server, go to Administrative Tools, Computer Management.
2. Expand Services and Applications.
3. Right click on WMI Control, then select Properties.
   
4. Select the Security tab.
5. Click Security.
   
6. Add the scan user (if needed), and then be sure to check Remote Enable for the user/group that will be requesting WMI data.
   

Further Investigation

If the above steps didn’t help, Alert Logic recommends installing the WMI Administrative Tools from Microsoft. This includes a WMI browser that will let you connect to a remote machine and browse through the WMI information. That will help to isolate any issues in a more direct and simple environment. Once the WMI browser can access a remote machine, Alert Logic should have access as well.

UNIX/Linux authenticated scanning

All UNIX and Linux authenticated scanning (security patch scanning) is performed with Secure Shell (SSH) access using a standard user account.

UNIX/Linux operating system types

Alert Logic scanning supports the following operating systems for authenticated scanning:

• Amazon Linux AMI
• CentOS
• Debian
• Fedora
• RedHat
• SuSe
• Ubuntu

If the authentication failed, the scan report will list Exposure ID: 16205 - Local Checks Error.

Authenticated scanning in an Amazon Web Services environment

For authenticated scans to work properly in your environment, you must have your AWS security groups set to allow full access by the scanning appliance. Doing so allows a Cloud Insight appliance to communicate with client instances, so the authenticated scan can detect all possible vulnerabilities and configuration issues. Alert Logic installs appliances alongside the instances inside each Amazon VPC.

By default, security groups are set up to allow full communication among group members. If you modify the default settings, authenticated scans may not reflect a full picture of your instance.

Credential storage

Type	Encryption type	Notes
Front end web traffic	TLS 1.2 and AES 256 bit encryption, via HTTPS	User credentials are encrypted using the public key from the FusionVM server, and only the FusionVM server can decrypt the information.
FusionVM back end	RSA and Api call EncryptByAsymKey, 2048 bit key length	Encryption of user passwords and authentication credentials for scanned systems is handled by MS-SQL server.
Scanning appliances	RSA and DSA, 2048 bit key length	Encryption by OpenSSH in SSH connections between the Appliance and the FusionVM server. Scanning appliances do not have anything encrypted on the appliances except the password file for appliance login authentication.

Web application testing

Alert Logic scanning looks for sample/default web pages left from an installation and commonly named files and folders that draw attention from malicious users. Some additional tools check web applications for rudimentary validation errors.

PCI scanning for web applications

Comprehensive web application scanning is a standard part of Alert Logic PCI scans. Web application scanning enhancements offer hierarchically deep, page-level scanning of common attack vectors including SQL injection and cross-site scripting. The scanning system indexes web servers and builds a list of hierarchical URL links in the website. Web application checks are performed separately for each URL to provide sitewide coverage.

Other web application scanning features

• SQL injection: Check if SQL parameter injection is allowed on the query parameters
• Cross−site scripting: Check if cross−site scripting (XSS) is allowed on the query parameters
• HTTP PUT allowed: Check if the PUT option is enabled at server directories
• Directory index-able: Check if the server directories can be browsed
• Obsolete files exist: Check if obsolete files exist
• CGI scanning: Test for common check web pages

Spider capabilities

A spider crawls websites and gathers as many URL links as possible. These links provide the list of URLs the scanner targets for testing. Spider functions include:

• Crawling HTTP and HTTPS websites based on given URL
• Cookie support

The spider has the following limitations:

• SSL websites with invalid certificate cannot be crawled
• Some ‘malformed’ URLs in HTML pages cannot be recognized
• URLs generated by Javascript cannot be found using this spider

Wireless networks

Wireless environments are transparent to the Alert Logic scanning system. Wireless devices have IP addresses and run applications just like other network systems. In that sense, wireless devices are assessed for security by Alert Logic. However, Alert Logic scanning is based on the Network layer (specifically IP only) and above; lower levels such as Data Link (PPP, SLIP, Ethernet, 802.11b, ATM, Frame-relay) and physical (Fiber, Cat-5, Cat-3, phone line, serial cable) are not within the scope of a network-based assessment.

Vulnerability and exposure library

Vulnerability sources

Alert Logic uses a variety of vulnerability suppliers: public, commercial, third-party, and vendor-driven.

• Security Focus (bugtraq, pentest, incidents, vulndev)
• Cert
• Vulnwatch
• OSVDB
• CVE
• NVD
• I-Cat
• Other vendors

Severity ratings

Alert Logic severity ratings come from the method used by the National Institute of Standards and Technology National Vulnerability Database, and are based on the CVSS Base Score.

Alert Logic assigns each vulnerability one of the following severities based on the CVSS score:

Severity	CVSS base score
Info	0.0
Low	0.1 - 3.9
Medium	4.0 - 6.9
High	7.0 - 10.0

CVE numbers

The Common Vulnerabilities and Exposures (CVE®) enumeration system was developed by the MITRE Corporation. The CVE website provides more information.

Use the CVE number to find vulnerability text that other vendors/researchers have made available or correlate vulnerability assessments with IDS data.

Types of vulnerabilities

Dangerous default settings

Dangerous default settings can come in various forms, including:

• Leaving sample pages/scripts on an IIS installation
• Not changing the manager password from "manager" on a 3Com hub/switch
• Leaving public/private as SNMP community names on a SNMP enabled device
• Failing to set the sa password on a MS-SQL server

Software features and best practices

Attackers can take advantage of usability features for a system or application and use them to access your network. For example:

• ICMP timestamp/netmask requests
• Microsoft netBIOS protocol
• Expand/Verify commands of Sendmail
• Ident services displaying the owner of running processes

Misconfigurations

Alert Logic designed the scanning system to separate true misconfigurations from default out-of-the-box settings. Common misconfigurations that are identified and reported include:

• SMTP relay
• Unrestricted netbios file sharing
• DNS zone transfers
• FTP world writeable directories
• Default administration accounts without passwords
• Open FrontPage websites
• NFS world exportable directories

Vendor flaws

Vendor flaws is the largest category. It includes buffer overflows, string format issues, directory transversals, and cross-site scripting. This category includes any vulnerability that requires a patch or an upgrade to fix.

Related topics