Alert Logic FAQs

Alert Logic offers product training through our online learning management system, LEARN. This on-demand learning portal allows you to tailor learning to your needs and consume the material on your own schedule.

Further, the LEARN system provides single sign-on with the Alert Logic console. If you are already logged into the console, you will be directed to the LEARN portal home page. If you are not already logged into the console, you will be directed to the Alert Logic console's login page to provide your product credentials, and then to the LEARN portal home page.

Overview

Alert Logic web application services use Request for Comments (RFC) standard parsing libraries to process request bodies into name-value pairs for further review. If the Alert Logic web application service has trouble parsing request bodies into name-pair values, it may throw a violation pertaining directly to the Content-Type or an erroneous false positive violation based on parsing the initially observed content.

When utilizing web application intrusion detection system solutions, Alert Logic recommends that you adhere to RFC web application standards for Content-Type to ensure successful name-value pair analysis and a more secure overall policy.

Web Application Firewall Violations

If Alert Logic encounters issues while attempting to parse request bodies into name-value pairs, it may throw one of these following web application firewall violations regarding Content-Types:

Malformed Request

A malformed request violation implies that Alert Logic is not able to successfully parse a request body based on conventional Content-Types - often XML, JSON, and multi-part requests. There are a few reasons why this violation could occur:

The Content-Type is text/plain

The Content-Type is relatively unconventional or completely custom

Content-Type Not Enabled

A Content-Type not enabled violation implies that Alert Logic is not able to successfully parse a request body because the configuration has not enabled parsing and validation of the more unconventional Content-Type headers - including application/octet-stream, application/x-amf, and text/plain. There are a few reasons why this violation could occur:

The Content-Type is text/plain

The Content-Type is relatively unconventional or completely custom

Violation Remediation Recommendations

Use these recommendations to remediate the above violations, as well as to maintain RFC and Content-Type best practice use.

Apply Proper Content-Type Headers

Ensure Content-Type headers match the request body content:

JSON - application/json

XML - application/xml or text/xml

Multi-part requests - multipart/form-data;boundary="BOUNDARY"

Ensure Proper Syntax

Confirm that the request body content has proper RFC standard format and syntax.

JSON

Make sure that the name-value pairs have proper delimitation and that the objects are properly nested. Use the MetaCPAN JSON encoder/decoder and JSON::Relaxed resources for guidance on this.

XML

Make sure that there is only one root node, that all tag elements are properly nested, and that if a prolog declaration exists it is the first line item. Use the MetaCPAN XML::LibXML resource for guidance on this.

Multi-Part Requests

Make sure that the multi-part boundary in the Content-Type header matches the boundaries in the request body. Further, confirm that the last boundary ends with a trailing double dash (--) to properly terminate the request body. Use the World Wide Web Consortium Multipart Content-Type resource for guidance on this.

Communicate Custom Content-Type and Text/Plain

Ensure that Alert Logic is notified if:

Web applications use text/plain

Web applications use unconventional or custom Content-Types

Further, enable text/plain parsing and bypass custom Content-Types when needed.

Threat Summary

Overview

Jenkins versions 1.4 - 2.46.1 and 2.5 - 2.56 are vulnerable to unauthenticated remote code execution (RCE) through the Jenkins remoting CLI. Attackers are able to bypass blacklist-based protections by including a Java 'SignedObject' to common deserialization gadgets, which leads to RCE when passed to a Java ObjectInputStream.

Exploitation

Stages

The attacker sends an empty HTTP POST request with Side:download and Session HTTP headers to the vulnerable Jenkins server.

The attacker sends an HTTP POST request with Side:upload and the same Session ID in the HTTP headers to the vulnerable server. The request contains a serialized java SignedObject object.

The server sends an HTTP 200 OK in response to the Side:download request (1). The response contains a serialized Java Hudson response object preceded by a string that indicates compromise.

The server sends an empty HTTP 200 OK in response to the Side:upload request (2).

Prerequisites

The attacker can access and exploit the Jenkins CLI remotely and without authentication.

Alert Logic Coverage

Alert Logic has evaluated its customer base for exposure to the exploit and has developed signatures for mitigating the threat depending on the security service in place.

The Network-Based Intrusion Detection System (IDS) has been updated with the new signatures for this exploit when detected via Alert Logic Threat Manager. If this signature is detected, an incident is generated in the Alert Logic console.

Detection of this threat is provided via Alert Logic ActiveWatch for Web Security Manager service. Depending on your deployment of Web Security Manager, you will receive an incident (for out-of-band deployment) or the threat will be actively blocked and rejected (for the inline Web Security Manager Premier deployment) if an exploit attempt is observed.

Recommendations for Mitigation

Upgrade to a non-vulnerable version to mitigate this vulnerability.

In This Article

Intrusion Detection System Blocking

Configuration Order

Incident-Based Blocks

Event-Based Blocks

Blocking Policy Recommendations

Description

Blocking is a feature used within the Alert Logicnetwork intrusion detection system (IDS) to prevent an attacker from accessing a host via a specific port, signature type, or host on a firewall. Within the Alert Logic console, you canaccess, view details of, search, roll back, or reissue blocking actions that have been instituted on your network. You can find detailed instructions on these blocking actions with our Blocks documentation.

This article describes all that goes into blocking with the Alert Logic IDS and what is required to successfully set up a blocking policy, as well as recommendations for creating an effective blocking policy.

Return to top

Intrusion Detection System Blocking

With IDS blocking,a block isonly issued after a threat event has been recognized. When a threat event isrecognized, a shun command isissued to the configured firewall, blocking malicious connections through the firewall. After the allotted time, the IDS logs back in and issues a no-shun command, removing the block on the firewall.

Because the IDS is passively deployed, it is not possible to achieve inline blocking. However, it is possible to issuea block and create an incident for the same traffic.

It is important to set up an effective whitelist policy as a first response to possible attacks in all cases of blocking. You can learn more about creating, editing, assigning, and deleting whitelist policies for the Alert Logic IDS within our Whitelist Policies documentation.

Return to top

Configuration Order

Alert Logic suggests that you follow a specific configuration order when configuring blocking policies. Use the following guidelinesto get the most out of your Alert Logic IDS blocking capabilities:

Configure Whitelist PoliciesA whitelist policy is required for blocking to work correctly. Some value must be entered, even if it is as general as 127.0.0.1. Whitelist policies should contain your internal network ranges and any external CDN and Authorized Scan IP ranges you expect to encounter. Find further information and step-by-step instructions on configuring whitelist policies within our Whitelist Policies documentation.

Configure FirewallConfiguring a firewall is a required step in configuring blocking policies. Find detailed information and step-by-step instructions on configuring a firewall within our Add a firewall and associated credentials documentation.Before setting up blocking policies, you must determine and select the zone(s) on which you want to use the blocking functionality. Be aware that incident-based blocks issue blocks to all firewalls by default, regardless of the source. You can change this in the Alert Logic console by setting up zones and enabling zone-based blocking. Information on zones and zone-based blocking can be found in our Select a zone documentation.

Configure Blocking PoliciesPlease note that the configuration order that Alert Logic is suggesting requires whitelists to be active on sensors before blocking policies are configured. This prevents blocks on internal servers from occurring. Follow the configuration order outlined above before configuring blocking policies.The Alert Logic IDS can perform two types of blocks - incident-based blocking and event-based blocking. Each has its own strengths and weaknesses, which will be discussed in each respective blocking type's section below- Incident-Based Blocking and Event-Based Blocking.Information and step-by-step instructions on configuring blocking policies can be found inour Blocking Configuration documentation. Recommendations on setting up blocking policies can be found below, in the Blocking Policy Recommendations section.

Return to top

Incident-Based Blocking

Incident-based blocks shun on the chosen source or destination where the incident is created. When setting up a blocking policy, you can choose the minimum incident threat rating that is required to issue a block.

Incident-based blocking allows for very high fidelity. With incident-based blocking, the attacker and victim are normalized, meaning the source is the attacker and the destination is the victim. Incident-based blocking requires incident correlation and may slow response time.

Alert Logic recommends that you block application attack, brute-force, and denial of service incidents as first-time incident classes. Keep in mind that commercial vulnerability scans are classified as recon. Use caution when blocking this class, as you will need the proper whitelists to correctly configure these blocks.

Return to top

Event-Based Blocking

Event-based blocking blocks based on single events. Blocks are not normalized; therefore, each event must be configured to block on source or destination, depending on the event signature. Event-based blocking allows for quick response times, as the IDS handles these blocks locally.

There are two types of event-based blocks: those with a severity of zero - Severity 0 - and those with a severity higher than or equal to 1 - Severity >= 1.

Severity 0

Severity 0 event-based blocks are issued by the IDS immediately when a signature matching a configured policy is seen. The sensor will tell the portal that a block has been issued. This means that by the time you see an event-based block in the UI, the block has already been issued.

Note:Blocks issued like this will follow the signature's literal source and destination. They will ignore XFF (X-Forward-For) and True-Client headers. Be aware of this when implementing blocks.

Severity >= 1

Event-based blocks with a severity of 1 or above will be processed by the Alert Logic ActiveAnalytics Platformbefore a block is issued. This has three main effects:

The event will be normalized so that the source is the attacker and the destination is the victim.

The event will have a threat rating assigned to it by our ActiveAnalytics Platform, which will be used to decide if a block should be issued or not.

The delay to block will be roughly equal to incident creation time.

Adding Events to the Blocking Policy

You should base event blocks off of events seen on your network. Consult an Alert Logic analyst to assist you in choosing the relevant events to block on.

Once you have discussed which events should be blocked with an Alert Logic analyst, you can find those events and block them within the console. Log in to the Alert Logicconsole and follow these steps:

Click the Configurationmain menu tab.

Click the Network IDSsub-menu tab.

Click Blocking Configurationfrom the left side panel.

Choose Policies from the tabs in the middle of the page.

Choose the appropriate signature or incident class, as decided with the Alert Logic analyst, from theAvailable Signaturesdrop down list.

Choose the appropriate event from the populated box under the drop down list, and clickAdd.

Return to top

Blocking Policy Recommendations

First-time blocking policies should start with incident-based blocks. Three incident types will cover around 95% of all detected attacks. These incidents include:

Application attack

Brute force

Denial of service

Recon

Note: Vendor scans now fall under the classification of suspicious activity.

It is not recommended to block on Trojan/Worm incidents, as these can flood firewalls and require very specific whitelist policies to allow internal workstation blocks.

Event-based blocks should be created for events that have been seen within your network.

Return to top

The public API does not return data for legacy physical Threat Manager appliances. The status and any other operational details about these appliances must be pulled by Alert Logic. To obtain this information, contact Alert Logic Support.

Threat Summary

Overview

A vulnerability has been found in BuilderEngine, allowing the upload of a malicious file, which would result in arbitrary remote code execution.

Exploitation

Stages

The malicious user performs an HTTP POST request that includes a malicious PHP file.

The vulnerable server responds with a successful status HTTP 200 OK.

The malicious user accesses the PHP file uploaded to the server.

Prerequisites

Attack can be carried out without authentication. Attacker must be able to contact the victim host.

Vulnerability Description

A vulnerability has been found in BuilderEngine 3.5.0 via elFinder 2.0. The jquery-file-upload plugin can be abused to upload a malicious file, which would result in arbitrary remote code execution under the context of the web server.

Alert Logic Coverage

Alert Logic has evaluated its customer base for exposure to the exploit and has developed signatures for mitigating the threat depending on the security service in place.

The Network-Based Intrusion Detection System (IDS) has been updated with the new signatures for this exploit when detected via Alert Logic Threat Manager. If this signature is detected, an incident is generated in the Alert Logic console.

Recommendations for Mitigation

The primary mitigation strategy consists of configuring the setting on line 93 for "/themes/dashboard.assets/plugins/jQuery-File-Upload/server/php/UploadHandler.php" to accept only desired files. The example provided only allows for GIF, JPEG, and PNG files to be uploaded.

'accept_file_types' => '/\.(gif|jpe?g|png)$/i'

Furthermore, this feature should be blocked to only trusted host. In most cases, ordinary users should not be allowed to upload to the CMS. A properly configured htaccess file will provide an additional defense against this attack.

Lastly, the web server should only be allowed to execute files that are trusted or files that are located in trusted directories. If the CMS must allow for files of any type to be uploaded from untrusted users and hosts, it is mandatory that those files are never allowed to be executed.

Threat Summary

Overview

The WordPress plugin called Cherry Plugin has a vulnerability which enables an attacker to upload files directly to the server. These files may then be executed by the attacker remotely to execute code or carry out other malicious activities.

Exploitation

Stages

The attacker sends a POST request to wp-content/plugins/cherry-plugin/admin/import-export/upload.php.

The attacker can access the file at wp-content/plugins/cherry-plugin/admin/import-export/<malicious file>.

Prerequisites

No prior authentication is needed to create a successful exploit

Vulnerability Description

There is an arbitrary file upload in the Wordpress plugin called Cherry Plugin. The vulnerability is caused by the lack of input validation and access control in the files upload.php. An unauthenticated user can make a request to upload.php, uploading an arbitrary file to the server. From here, the attacker could compromise the confidentiality, integrity, and availability of the server.

Alert Logic Coverage

Alert Logic has evaluated its customer base for exposure to the exploit and has developed signatures for mitigating the threat depending on the security service in place.

The Network-Based Intrusion Detection System (IDS) has been updated with the new signatures for this exploit when detected via Alert Logic Threat Manager. If this signature is detected, an incident is generated in the Alert Logic console.

Recommendations for Mitigation

Upon discovery of a successful exploit, customers are expected to take normal reasonable action in accordance with their own standard operating procedure, such as:

Isolate the compromised device from the network

Wipe and reinstall the device from secure media

Patch the vulnerability from a trusted source (or otherwise mitigate with FW, config, etc.)

Replace data from backups

Test the device

Return the compromised device to the network and full operation

Yes, internal and external scanning will evaluate standard web-applications (Wordpress, Joomla, etc.) for known vulnerabilities, including SQL-injections, cross-sitescripting, and the rest of the OWASP Top 10.

Additionally, PCI scanning will perform in-depthweb-applicationscanning of customweb-applications as required for PCI ASV certification, checking for OWASP Top 10 and beyond.

Note: The following information applies to all customers who are using the new Alert Logic Incident Console.

Overview

Webhooks allow you to send real-time data from Alert Logic directly to a third-party application - more specifically, any public-facing web server configured to handle HTTP callbacks. You can now configure webhooks within the Alert Logic console to send incident notifications to a target webhook URL that you configure.

Within the Alert Logic console, you can configure and test webhooks, as well as configure and manage incident notifications to be received via webhooks. See more detailed information on these capabilities - including configuring, managing, and setting up notifications for webhooks - in our Webhooks documentation.

Configuration Capabilities

To add a webhook in the Alert Logic console, navigate to the Settings menu ( Configure your webhook incident notifications ) < Webhooks > yellow plus sign (). A sidebar will appear, within which you will enter a name and target URL for your webhook and test the JSON to confirm it has been successfully added.

For more detailed steps and information on configuring webhooks, see the Add a new webhook documentation.

Notification Capabilities

To configure notifications for webhook incidents in the Alert Logic console, navigate to the Settings menu () > Notifications > Manage Subscription of Others. At the bottom of a given account, you will see the current webhook notification settings. To manage the settings, click on the desired webhook and add accounts to Escalations or Threat Levels.

For more detailed steps and information on configuring webhook notifications, see the documentation.

Overview

Alert Logic SIEMless Threat Management Essentials and Professional offerings are licensed based on the number of nodes that are protected in your environment. The following article describes what a node is and how node usage is calculated.

Cloud Environment Nodes

For customers with Amazon Web Services (AWS) or Microsoft Azure deployments, Alert Logic integrates with Cloud Provider APIs to determine the number of AWS EC2 and/or Azure Virtual Machine instances in your defined protected networks.

Individual Containers are not counted as nodes. Rather, Alert Logic counts the underlying instances. Similarly, cloud services not deployed on instances in your environment are not counted as nodes. If you stay below 100MB of log data per licensed node per day, these additional sources are effectively "free." If aggregate account usage exceeds an average of 100MB per node per day, Alert Logic provides offerings to cover the additional data.

Node usage snapshots in AWS and Azure are taken hourly; all hourly measurements are averaged to calculate usage for a given month.

On Premise Environment Nodes

Alert Logic identifies nodes for on-premises environments via two different methods. First, hosts with successfully provisioned agents are always counted as nodes. Even when a host has multiple IP addresses, it will be counted as a single node.

Since not all hosts in your protected network may have an agent - such as network devices, for example - discovery scans are also used to identify nodes. Discovery scans are performed daily and will capture any device in a protected network with a port open.

Node usage is calculated by de-duplicating agent and discovery scan results. Daily node counts are averaged over a calendar month to determine usage.

Node Usage

Usage is aggregated across all deployments - AWS, Azure, on-premises, etc. As long as your average number of nodes for the month is less than your entitlement, you are within your license. This methodology offers several benefits:

Nodes are a simple concept. It is far easier to count servers and network devices than it is to estimate log volume and network traffic.

Alert Logic measures usage based on average utilization rather than peak or 95th percentile. This reduces licensing costs and volatility, particularly for cloud customers operating variable workloads.

Alert Logic does not charge for serverless data sources, so long as you stay within the 100MB per day per node data entitlement. We see that 100MB per day per node is adequate for most customer workloads and provides some room for additional serverless data sources.

When a customer is deployed in AWS or Azure or when an agent is present in another environment, Alert Logic only charges for a single node for hosts with multiple IP addresses.

Note: Alert Logic does not count its own appliances as nodes, and whitelisting does not factor into node count.

Description

A whitelist policy allows you to define a list of IP addresses allowed to communicate with hosts in the Alert Logic protected network. Whitelists help ensure you do not use resources monitoring permitted communication.

Applying a Whitelist Policy to an Agent

Once a whitelist policy is created, the whitelist policy must be assigned to an assignment policy /appliance. The assignment policy then applies the whitelist policy to the agents with that particular assignment policy, and therefore will stop the agent sending the traffic to the appliance.

For procedures on creating a whitelist policy and assigning the policy to an appliance, refer to our Whitelist policies documentation.

Applying a Whitelist Policy to a Span Port/Network

Once a whitelist policy is created, the whitelist policy must be added to a monitoring policy. With this set up, the traffic is dropped when received via a span port and therefore will not be sent to the appliance.

For a procedure on creating a whitelist policy, refer to Create a whitelist policy.

For a procedure on creating a monitoring policy, refer to Create a monitoring policy. Step 7 in the procedure describes how to assign a whitelist policy to the monitoring policy.

Additional Information

For more information about whitelist policies and other intrusion detection system policies, refer to our Threat Manager Policies documentation.

Customers may add secure socket layer (SSL) certificates to their websites to secure their information. A browser connecting to the secure server will use the SSL protocol to connect and verify the servers certificate. However, customers can also use Mutual Authentication to have both the client and server use signed certificates to authenticate each other. With Mutual Authentication, both client and server will provide signed certificates for verification.

How Mutual Authentication Works

Client sendsClientHellomessage proposing SSL options.

Server responds withServerHellomessage selecting the SSL options.

Server sendsCertificatemessage, which contains the server's certificate.

Server requests client's certificate inCertificateRequestmessage, so that the connection can be mutually authenticated.

Server concludes its part of the negotiation withServerHelloDonemessage.

Client responds withCertificatemessage, which contains the client's certificate.

Client sends session key information (encrypted with server's public key) inClientKeyExchangemessage.

Client sends aCertificateVerifymessage to let the server know it owns the sent certificate.

Client sendsChangeCipherSpecmessage to activate the negotiated options for all future messages it will send.

Client sendsFinishedmessage to let the server check the newly activated options.

Server sendsChangeCipherSpecmessage to activate the negotiated options for all future messages it will send.

Server sendsFinishedmessage to let the client check the newly activated options.

How the Client and Server Accomplish Each of the Checks for Client Authentication

Digital Signature: The client sends a "Certificate Verify" message that contains a digitally signed copy of the previous handshake message. This message is signed using the client certificate's private key. The server can validate the message digest of the digital signature by using the client's public key (which is found in the client certificate). Once the digital signature is validated, the server knows that the public key belonging to the client matches the private key used to create the signature.

Certificate Chain: The server maintains a list of trusted Client Authorities (CAs), and this list determines which certificates the server will accept. The server will use the public key from the CA certificate (which it has in its list of trusted CAs) to validate the CA's digital signature on the certificate being presented. If the message digest has changed or if the public key does not correspond to the CA's private key used to sign the certificate, the verification fails and the handshake terminates.

Expiration Date and Validity Period: The server compares the current date to the validity period listed in the certificate. If the expiration date has not passed and the current date is within the period, then this check succeeds. If it is not, then the verification fails and the handshake terminates.

Certificate Revocation Status: The server compares the client certificate to the list of revoked certificates on the system. If the client certificate is on the list, the verification fails and the handshake terminates.

Additional Information

Verify the Client Certificate with auth-root

Run the following command to verify the client certificate:

openssl verify -purpose sslclient -CAfile auth-root.crt testcert.crt

Test Connection with Client Cert

Run the following command to test the connection with the client:

openssl s_client -servernameexample.com-connectexample.com:443 -key client-cert.key -cert client-cert.crt

In This Article

Overview

Stay Up to Date

Configuration

Network Availability

Authentication and Accounts

Sources and Further Reading

Overview

The following article describes best practices and recommendations for reducing the security risk of internet-exposed endpoints. Following these recommendations can help you build a foundation on which to construct security practices for your endpoints.

Stay Up to Date

Many software providers offer mailing lists, RSS feeds, or other notifications for when new versions become available. Subscribing to these notifications can help you keep your software up to date while reducing the workload needed to constantly search for updates.

Keep all services, especially external-facing services, up to date. To accomplish this, you should review vulnerabilities on a regular basis to quickly identify and prioritize patches against vulnerabilities that pose the greatest risk.

Many applications and services have the option for automatic updates. The potential for issues originating from automatic updating should be weighed based on how a system is used and the criticality of the systems availability. Where this is not possible, a structured patch management program should be in place to validate updates prior to deployment.

Recommendations:

Subscribe to software update notifications from vendors.

Implement a patch and vulnerability management program.

Turn on auto-update wherever possible.

Configuration

Default to secure versions of protocols, such as SFTP instead of FTP and HTTPS instead of HTTP. This prevents a variety of attacks, including man-in-the-middle attacks. Disable the ability to downgrade to an insecure version of a protocol to prevent downgrade attacks. For example, disable SSH v1 and TLS 1.0.

Note: In order for Alert Logic to monitor and alert on SSL/TLS traffic, the certificate and key must be uploaded to the Alert Logic console and the cipher suite may not include any Diffie-Hellman-based ciphers. Alternatively, the encryption may be terminated prior to reaching the Alert Logic appliance.

It is good practice to log out idle users and close idle sessions. This limits exposure to session hijacking, which can be especially threatening if a users physical device becomes compromised. Common idle timeout ranges are 2-5 minutes for high-value targets and 15-30 minutes for lower-value targets.

Recommendations:

Default to more secure versions of protocols.

Configure services to disconnect idle users.

Network Availability

Reduce your attack surface by limiting network access, including accessible addresses, ports, and services, to those required to run the business. A reduction in attack surface reduces the resources required to monitor the attack surface as a whole, allowing for focus on the threats that are most dangerous.

Recommendations:

Only enable public-facing services on systems where they are absolutely necessary. For example, if hosting a website, only the ports serving the site ports 80, 443, 8080, etc. need to be open to the Internet.

Allow traffic only to/from trusted addresses and networks.

Allow access only to/from users who have already authenticated and connected securely, such as via VPN or RD gateway.

Deny connections by default and allow by exception. The default behavior of a system should be to deny access, allowing access only from trusted systems rather than allowing all access and denying known bad actors.

Authentication and Accounts

Enforce least privileged access for accounts, especially for automated processes. Do not give an account more access than it needs. Ideally, you should prefer keys and certificates over passwords. Additionally, you should require that the keys and certificates have a passphrase.

Note: In many cases (such as SSH), this must be enforced by internal policy rather than by system configuration.

For user sessions, implement multi-factor authentication (MFA). Keep in mind that requiring knowledge-based factors such as security questions in addition to a password does not constitute MFA, as both factors are knowledge-based. The secondary factor should be something possession-based (something you have, such as a smart card or security token) or biometric-based (something you are, such as a fingerprint or face scan).

Note: SMS-based MFA is vulnerable to attacks such as phone cloning or social engineering attacks against the cell provider.

Set expiration dates on keys and certificates. While password expiration is no longer recommended, key expiration is. Rotating keys does not require that users learn a new key and can be largely automated, requiring little or even no input from users.

Recommendations:

Periodically review access, removing or reducing access where appropriate.

Disable login as the admin or root user and escalate privilege (e.g. with sudo ) once connected, if necessary.

Trust relationships should not cross release environments. For example, the SSH keys for the testing environment should not work for the production environment. This prevents a compromise in one environment from spreading to another.

Implement brute-force protections such as Fail2Ban.

Sources and Further Reading

NISTIR 7966 - Security of Interactive and Automated Access Management Using Secure Shell (SSH)

NIST SP 800-131A Rev 2 - Transitioning the Use of Cryptographic Algorithms and Key Lengths

NIST SP 800-46 Rev 2 - Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security

NIST SP 800-171 Rev 1 - Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations

NIST SP 800-41 Rev 1 Guidelines on Firewalls and Firewall Policy

OWASP Session Management Cheat Sheet

Agent Encryption

At install/activation, the Alert Logic agent uses the customer provisioning key from the UI to connect to our datacenter services using server side SSL encryption. During this initial exchange, the agent identity is activated and an agent-specific key/identity is placed locally on the host system running the agent.

All further communication is carried out via the same server side SSL encryption exchange, with the agent using the key to establish its identity.

Agent-to-Appliance Traffic Security

The agent's private TLS RSA keys are stored in the following files:

On Linux: /var/alertlogic/etc/host_key.pem

The SSL certificate using this key is host_crt.pem

On Windows (32-bit): C:\Program Files\Common Files\AlertLogic\host_key.pem

On Windows (64-bit): C:\Program Files (x86)\Common Files\AlertLogic\host_key.pem

The file access masks/lists are modified so that only root/administrators/localsystem can read these files. They are in PEM format (base64-encoded ASN1 blob). No passphrase is used.

The keys are used at handshake only to exchange a shared AES key. Beyond that, symmetric AES encryption is used. The key and its associated certificate can be deleted, at which point a service is required for the host to obtain a new key, and with it a new identity. The exception is hosts migrated from LM2 (those will use the LM2 agent ID when requesting an identity, and so it will get the same one). The provisioning key must be entered at Windows installation (PROV_KEY=parameter or in GUI), or input after Linux install with "/etc/init.d/al-log-agent configure --key ...") in order for this to work. Otherwise, an agent will sit there waiting for keys. With a new identity, a host will register a new list of default sources (event log for Windows, syslog for Linux), so this will not work for flat file sources. These need to be recreated manually.

In This Article

Description

What Is Phishing and How Does It Work?

Who Is a Target?

Common Phishing Themes and Indicators

Practical Advice

Additional Resources

Description

Phishing is a social engineering technique that is becoming an increasingly common threat. It is currently considered the number one vector for malware infections. The following article describes some key aspects of phishing, as well as practical advice on spotting phishing messages.

What Is Phishing and How Does It Work?

Phishing is a technique where there is an attempt to fish for confidential information. The end goal is to steal sensitive data, infect devices, or simply cause disruption to an organization. By sending phishing emails or messages, attackers hope to gain sensitive information from the victim (such as credentials to log into a system) or to infect devices with malware, which can perform malicious actions like giving the attacker remote access to devices. Naturally, this can lead to the disclosure of confidential information and, thus, data breaches.

Phishing is most often carried out via email, but SMS and phone call phishing is also common practice. These techniques are sometimes referred to as smishing and vishing, respectively.

Phishing attacks can be carried out in various ways, so there are different red flags to look out for. An attacker may pretend to be from a certain department within the victims organization and ask them to reply to the email with the informationthey'relooking to obtain. Phishing can also be achieved indirectly - for example, by getting the victim to navigate to a legitimate-looking website (often a copy of a real and well-known website) where the victim attempts to log in, which ultimately discloses the victims login credentials to the attacker.

As for malware infections originating from phishing emails, attackers can easily achieve this by getting their victim to click on malicious links or download attachments containing malware sent within the email that is often disguised as something else and of an urgent nature.

Who Is a Target?

Mass phishing emails tend to target everyone at an organization, or several organizations, indiscriminately these emails are vague enough that their content could apply to most people. Because they are quite general, the rate of success for the attacker is likely smaller; however, this is balanced by the fact that they are sending the email to hundreds or even thousands of people at once.

In order to make their attempts more believable and increase their chances of being successful, attackers may resort to spear-phishing. This is targeted phishing, meaning that the attack is conducted in a way that targets a specific organization, department, or group of people, by tailoring the contents of the email or message so that they are more relevant and believable. This often means that they address the victim by name and might impersonate services used by that individual or the organization they work for.

Different people may be targeted for different reasons. The higher the level of access someone has within an organization, the higher the risk posed by their account being compromised. An attacker may prefer to target these people in order to get higher privileges more quickly, but they are certainly not the only target. Phishing attacks targeting high-ranking people are sometimes called whale-phishing or whaling.

Attackers also often target non-technical staff, as they assume there is a lower level of awareness of phishing attacks within such departments. Employees who have a lot of information available on online platforms, such as LinkedIn, may also be at a higher risk of being targeted. For example, an attacker may find a victim's personal email address and send the phishing email to both personal and company email addresses, potentially making their request appear more legitimate to the victim. It is important to be conscious of what information is available online about them that could possibly be used in a phishing attempt.

In short, everyone can be a target.

Common Phishing Themes and Indicators

The subject lines of phishing emails will often use topics that people are likely to care about, such as promises of money prizes or alerts stating that something is wrong with the victims account. These subject lines often include information that serves as bait and attempts to exploit our natural human curiosity, making the target more likely to open the email.

Attackers may also try to trick victims by pretending to be someone of authority or a trusted party, such as their direct manager, the CEO of the company, a co-worker, the local authorities, or the tax/revenue office.

It is important to always double-check the sender email address. In more extreme phishing attempts, the attacker may gain unauthorized access to a legitimate email address from within the organization and use it to send their phishing emails to the rest of the organization. This, of course, greatly increases the chance of success for the attacker. Although this is uncommon, it is important for organizations to be aware that it is a possibility and for staff to remain vigilant. These emails will usually seem out-of-context or unlikely to come from that person. We recommend reporting any email containing phishing indicators, even if it comes - or appears to come - from within the victims organization.

Some other indicators include:

There is a sense of urgency and authority in the content of the email.

The sender is trying to make you download an attachment or click on a link with a degree of urgency.

When you hover over the link with your mouse, you can see that the true destination of that link is different. Note: This usually appears at the bottom left corner of your screen when hovering over a link in an email. For example, the email might read www.alertlogic.com but when hovering over the link you see that the true destination is www.alerltogic.com.

The email contains poor spelling and grammar issues, but this is not guaranteed. Messages can also be very well worded.

The email starts with a generic greeting that doesnt address the recipient by name, such as Hi or Dear customer.

There is a suspicious subject line that sounds like bait. Example: Youve just won $1,000,000!.

The sender email address is a misspelled version of a known domain or is a completely unknown domain irrelevant to your organization.

Practical Advice

Tip #1: Dont rush think before you click any links or download any attachments. Try to verify whether the communication is genuine without replying to the email.

Tip #2: Check the real link underneath a button or text on the body of the email by hovering over it with your cursor.

Tip #3: Notice whether the link starts with http or https. Most major legitimate websites use the secure protocol https. Although phishing websites using https have also been observed in the past couple of years, a link that starts with http is another possible indicator of phishing.

Tip #4: Be wary of shortened links. Attackers have begun using shortened links to hide their destination, so even when you hover over the text all you see is a short link that doesn't show the actual domain you will be sent to. Shortened links may look like https://bitly.com/2DZE9E, https://ow.ly/o6G7, or https://goo.gl/M2dd5. Finding out where these links are sending you is complex without clicking on them, so our best advice is to look for other indicators like the sender's email address and greeting. If the message doesnt appear to be legitimate overall, don't reply to the email and don't attempt to click on the shortened link.

Tip #5: If you do recognize the sender, consider calling them to ask whether they really sent you an email. If you receive an email from an institution, such as your bank, whose legitimacy you are unsure of, you can always contact the institution on a trusted email address or phone number.

Tip #6: If you suspect you have received a phishing email or message, report it within your organization so other employees can be alerted.

Tip #7: Question everything. Attackers will attempt to trick you by acting as high-profile colleagues. Ask yourself whether this email is unexpected or out of the ordinary for this person, or simply ask the person whether they sent you an email.

Tip #8: Always check the domain name in the email. Attackers can craft domain names that will appear legitimate, but if a domain looks like alertlogic.com.fakedomain.com - with a parent domain at the beginning followed by the sub-domain - it is fake and crafted by an attacker to trick victims. A real sub-domain URL will look like info.alertlogic.com, with the sub-domain preceding the parent domain.

Tip #9: Always check the spelling and grammar of an email. If an email has poor spelling and grammar, it is possible that something is amiss.

Tip #10: No matter how convincing an email may look, there is no reason for personal information to be requested within an email. A reputable company should never need to ask someone for their password, and a bank does not need someone to send your account number to them they already know it.

Tip #11: Phishers will eventually attempt to scam victims of their money by asking to cover expenses, taxes, etc. Should this happen, this is likely a scam - no reputable company will do this.

Tip #12: One of the main ways an attacker will attempt to trick victims into clicking on a malicious email is by crafting the email to look like it has come from someone in the users company or from a company the user has connections to. The best way to spot these emails is to know your contacts. As you go about their daily life, you will receive numerous emails from various sources some are expected, and some are not. Take extra care of the unexpected emails, as these can be malicious in intent. If the email is unexpected or is from a person/company you have no ties to, delete the email. If an email seems out of the ordinary from a contact, question it.

Additional Resources

National Cyber Security Centres (NCSC) Recommendations for a Multi-layered Approach to Phishing Defence: https://www.ncsc.gov.uk/guidance/phishing

Centre for the Protection of National Infrastructures (CPNI) Dont Take the Bait free resources: https://www.cpni.gov.uk/dont-take-bait

Googles free Phishing Quiz: https://phishingquiz.withgoogle.com

Overview

Alert Logicis actively researching an unauthenticated remote code execution (RCE) vulnerability in Atlassian Jira (CVE-2019-11581). This threat allows for RCE on a victim host, allowing an attacker to gain complete control over the victim, which may include installation of persistence.Exploit code has been released into the public domain,andAlert Logic hasobserved active attacks against ourcustomersusing this vulnerability.

Any customers withJiraexposed to the public internet and running the specified versions of Jira Server and Data Center listed in theRecommendations for Mitigationsection below are affected by this vulnerability. Atlassian recommends immediately upgrading to a non-vulnerable version of Jira Server and Jira Data Center.JiraCloudcustomers are not affected.

Vulnerability Description

According to Atlassian, CVE-2019-11581is a server-side template injection vulnerability in Jira Server and Data Center, in theContactAdministratorsand theSendBulkMailactions. For this issue to be exploitable,at least one of the following conditions must be met:

an SMTP server has been configured in Jira and the Contact Administrators Form is enabled; or

an SMTP server has been configured in Jira and an attacker has "JIRA Administrators" access.

In the first case, where theContact Administrators Form is enabled,attackersare able toexploit this issue without authentication. In the second case, attackers with "JIRA Administrators" access can exploit this issue. In either case, successful exploitation of this issue allows an attacker to remotely execute codeon systems that run a vulnerable version of Jira Server or Data Center.

Alert Logic Coverage

Vulnerability Scanning: Alert Logic hasdevelopedvulnerability scan coverage to identify vulnerable assets.

Network IDS: Alert Logic can identify the execution of this vulnerability with an existing telemetry signature; however, we are currently developinga specific signature to enable for more efficientmonitoring by the Alert Logic Security Operations Center.

Web Application:Existing Alert Logic web application coverage will detect attacks targeted at exploiting CVE-2019-11581. If the Alert Logic inline web application firewall is in Protect mode, it will also block these attacks.

Log Management:At this time, it is not expected that log detection is appropriate for this threat; however, Alert Logic will continue this assessment.

Recommendations for Mitigation

All versions of Jira Server and Data Center from 4.4.0 before 7.6.14 (the fixed version for 7.6.x), from 7.7.0 before 7.13.5 (the fixed version for 7.13.x), from 8.0.0 before 8.0.3 (the fixed version for 8.0.x), from 8.1.0 before 8.1.2 (the fixed version for 8.1.x), and from 8.2.0 before 8.2.3 are affected by this vulnerability.

Atlassian recommends that you immediately upgrade to the latest version. If you are unable to upgrade Jira immediately, a temporary workaround is available. For more information on affected versions, upgrading, and the temporary workaround, refer to JIRA Security Advisory 2019-07-10.

Updates

This section will be updated with new information about this vulnerability and related Alert Logic coverage as it becomes available. To follow updates for this vulnerability, click the FOLLOW button at the top of the article. You must be signed in to the Support Center using your Alert Logic product credentials to follow this article.

07/16/2019: Vulnerability scan coverage is now available to identify vulnerable assets.

Yes, an Alert Logic appliance is required for a customer to collect threat traffic. Alert Logic appliances are able to collect network traffic either directly from a span (mirrored) port from a network switch or from Alert Logic agents, which can be deployed on any host that you wish to protect.

In the case of span ports, network traffic can only be sent to an appliance that is sitting locally to the network switch. Similarly, agents can only send network traffic to a local appliance.

Alert Logic appliances come in both physical and virtual (.ova) options. Physical appliances are able to work with both agents and network spans, while virtual appliances only work with agents.

Note: The following information applies only to those customers who subscribe to the Alert Logic SIEMless Threat Management product.

Overview

Cross-network protection is now available for configuration in manual deployments within the Alert Logic console. The cross-network protection feature allows for a network configured with an appliance to provide protection to other networks under the same Alert Logic console account with agents installed.

Requirements

Cross-network protection is available for manual deployments in Amazon Web Services (AWS), Microsoft Azure, and data centers for network intrusion detection and/or scanning functionalities.

While you will be able to configure protecting networks and protected networks within the Alert Logic console, connectivity will only work if you have configured the networks to talk to each other within your environment. Further, protecting networks must have appliances configured, and protected networks must have agents configured. Requirements and configuration details can be found in our Cross-Network Protection documentation.

Configuring Cross-Network Protection

You can set up cross-network protection within a manual AWS, Azure, or data center deployment in the Alert Logic console by following the steps outlined in our Configure Cross-Network Protection knowledge base article. This information also includes removing cross-network protection connections.

Description

The following article describes how to reset your password for the Alert Logicconsole.

Solution

Access the log in screen for the Alert Logic console.

ClickForgot YourPassword?

On the Reset Your Password page, enter your email address in theEmail Addressfield and clickReset Password.

If the email address is associated with an Alert Logic account, you will receive an email from Alert Logic with instructions to reset your password. Follow the instructions in this email to reset your password and log in to the Alert Logic console.

Note: Alert Logic requires that your password be changed every 90 days and that it adheres to the following complexity requirements:

Cannot be identical to current or up to four most recent previous passwords

Length of at least 12 characters

Contain three of the four possible character types:

Upper case character

Lower case character

Number

Special character ( !"#$%&'()*+,-./:;<=>?@[]^_`{|}~ )

If you have followed the steps above and did not receive an email or are still not able to log in,consider the following:

If you do not see the email in your inbox, check your junk or spam folder for the email.

Double-check the email address entered to reset the password. If there is another possible email address associated with the account, trythe alternateemail address.

If you still cannot log in, call Alert Logic Support to check if your account is locked.US:877.484.8383(option 1)UK:+44 (0) 203 011 5533(option 1)

If your account is unlocked and you still cannot log in, contact your company's Alert Logic console administrator to check if your company account is locked.

For Windows, deployment of agents works fine with System Center Configuration Manager (SCCM) and other Windows deployment tools. For Windows and non-Windows, command line options give you full control over all the installation features available within the Alert Logic console.

Threat Summary

Overview

There is an insecure configuration/authentication bypass in the Oracle Glassfish server. This vulnerability allows a remote attacker to upload a malicious WAR file to execute arbitrary code on the server. This could lead to the compromise of the target system. In newer releases of the Glassfish server, remote access to the administration interface is not allowed by default.

Exploitation

Stages

The remote unauthenticated attacker sends the request common/index.jsf on the admin port of the Glassfish server to retrieve the version of the server.

The server responds with a 200 OK and the server version is in the response.

The attacker, utilizing the server version, will either authenticate to the server with the supplied credentials (in some versions, the default username is admin and the password ID is left blank) or they will bypass authentication by utilizing a lowercase HTTP request method, such as post instead of POST.

The server will respond successfully, indicating that the attacker has access to the administration interface.

The attacker uploads their malicious WAR file to the server and the server responds with a 302. This is an indication of success.

The attacker sends a GET request to their malicious file to initiate their shell on the system.

Post exploit, the attacker un-deploys their uploaded file after the shell has been injected.

Prerequisites

The attacker may need the administrator credentials if the authentication bypass vulnerability is not a viable option.

Alert Logic Coverage

Alert Logic has evaluated its customer base for exposure to the exploit and has developed signatures for mitigating the threat depending on the security service in place.

The Network-Based Intrusion Detection System (IDS) has been updated with the new signatures for this exploit when detected via Alert Logic Threat Manager. If this signature is detected, an incident is generated in the Alert Logic console.

Recommendations for Mitigation

Upgrade to a non-vulnerable version to mitigate this vulnerability.

In This Article

User Roles

Mapping of Roles to User Permissions

Additional Support

Overview

With the release of the New Alert Logic Console Universal Navigationcomes role-based access controls, which provide a unified way to manage authorization of and access controls for users. The addition of role-based access controls simplifies the management of user permissions in the Alert Logic console.

This article provides you detailed information on the five user roles available, as well as how these roles map to the user permissions, so that you can knowledgeably choose the appropriate user roles for your team.

Note:The phrase "assigned account" below refers to your own Alert Logic account. This is the default account that you will land on after you log in with your Alert Logic credentials.

Note:The phrase "managed account" below refers to any accounts that may be attached to your assigned account. These are like 'child' accounts that you can switch into. Managed accounts are used by decentralized organizations that want clear segregation between business units or by service providers with multiple customers.

User Roles

The following are the user roles available within the Alert Logic console:

Note:Checking the Notification Target Only box when creating or editing a user will allow the user to receive notifications but not access the products.

Administrator. The Administrator role allows you full management and read access on your assigned and managed accounts. This role is the only one that can create or delete users for both assigned and managed accounts. It also allows you to control features for your assigned and managed accounts.

Use this role primarily for user management and sparingly for your master and super-user account.

Owner. The Owner role allows you full management and read access to your assigned and managed accounts. You will not have the ability to create or delete users - you can only update users on your managed account.

Use this role to delegate daily configuration management activities on your assigned and managed accounts that do not include user management.

Power User. The Power User role is similar to the Owner role, but with view-only access to your managed accounts. You can do configuration management on your assigned account but can only view the information on your managed accounts - not change it. You cannot do any user management.

Use this role to delegate configuration management activities on your assigned account, but not to delegate management of managed accounts or of users.

Support/Care. The Support/Care role provides read access to your assigned and managed accounts.

Use this role to delegate read access to your assigned and managed accounts for individuals that need to be able to support and troubleshoot on these accounts.

Read Only. The Read Only user has read-only access to your assigned account and cannot view information on your managed accounts.

Use this role if you want to delegate visibility to your assigned account but do not want any visibility on your managed accounts.

The table below gives you a visualized understanding of the privileges of each role. It is important to note while reviewing the privileges thatyou only have downstream access to your accounts. If your account is managed, none of these roles allow you to see within the accounts above yours.

Administrator

Owner

Power User

Support/Care

Read Only

Full Access & User Management

X

Modify Managed Accounts

X

X

Modify Assigned Accounts

X

X

X

Read Managed Accounts

X

X

X

X

Read Assigned Accounts

X

X

X

X

X

Mapping of Roles to User Permissions

The roles outlined above map directly to the deprecated permissions. Utilize this information to choose the appropriate user roles for your team:

Administrator

Owner

Power User

Support/Care

Read Only

Create new users

X

Create new managed account users

X

Delete users

X

Delete managed account users

X

Lock users out of console

X

Lock managed account users out of console

X

Modify users

X

Modify managed account users

X

X

Run reports

X

X

X

X

X

Run reports on managed accounts

X

X

X

X

Configure filters

X

X

X

Configure managed account filters

X

X

View managed account events

X

X

X

X

Create managed accounts

X

Modify incidents

X

X

X

Issue containment requests

X

X

X

Modify signature details

X

X

Modify global configuration

X

Modify managed account global configuration

X

X

View event packet payload

X

X

X

X

X

Modify scan settings

X

X

X

Modify managed account scan settings

X

X

X

Modify tags

X

X

X

Modify managed account tags

X

X

Manage custom reports

X

Modify log policy

X

X

X

Modify managed account log policy

X

X

Modify log correlation policy

X

X

X

Modify managed account log correlation policy

X

X

Access public API

X

X

X

X

X

Impersonate other users via API

X

X

View log credentials

X

X

X

X

X

View log collection statuses

X

X

X

X

X

View managed account log collection statuses

X

X

X

X

Modify security options

X

X

X

Modify managed account security options

X

X

Hide vulnerabilities

X

X

X

View Management tab

X

X

X

X

Create and edit cases

X

X

X

X

Modify hosts

X

X

X

Create and edit custom cases

X

X

X

X

Close cases

X

X

X

X

View Web Security Manager (WSM) configuration

X

X

X

X

X

View managed account WSM configuration

X

X

X

X

Modify WSM configuration

X

X

X

Modify managed account WSM configuration

X

X

View certificates configuration

X

X

X

X

X

View managed account certificates configuration

X

X

X

X

View IDS whitelist configuration

X

X

X

X

X

View managed account IDS whitelist configuration

X

X

X

X

View notification contacts

X

X

X

X

X

Update, create, and delete notification contacts

X

X

X

View notification policies

X

X

X

X

X

Update, create, and delete notification policies

X

X

X

View notification contact groups

X

X

X

X

X

Update, create, and delete notification contact groups

X

X

X

View notification WebHooks

X

X

X

X

X

Update, create, and delete notification WebHooks

X

X

X

View notification history

X

X

X

X

X

Update, create, and delete notification history

X

X

X

Manage notifications

X

X

X

Notification target only

X

Additional Support

If none of the user roles laid out above seem to fit your needs, contact Alert Logic Support for additional guidance.

A course on this topic is available in our eLearning portal. To access this course, complete the following steps:

New Alert Logic Console Training Video

Go to the LEARN portal. If you do no have an account, clickRegister Hereand fill in the required information.

In the search field, enterAlert Logic Security Console. Select New Alert Logic Security Console Highlight Videofrom the results.

ClickRequest.

On the Transcript page, clickLaunch.

The Network IDS tab allows configuration of the network intrusion detection system in the Alert Logic console.

Policies

Protected Hosts

The protected hosts policy allows you to configure how the traffic is sent from the protected host to the Alert Logic threat management appliance. You have the ability to enable encryption of the traffic prior to being transported for analysis.

Blocking

Assignment

Assignment policies are used for specifying what IDS appliance a protected host sends the traffic to for analysis. More than one appliance can be added to a policy for redundancy.

In a dynamic environment where IP addresses often change, anassignmentpolicyensures that hosts always correspond to their appliances.

For more information, refer to our Assignment Policies help documentation.

Certificates and Keys

The Alert Logic SSL Decryptor extends the advanced intrusion detection capabilities ofthe intrusion detection system (IDS). The decryptor allows the appliance to inspect the encrypted SSL traffic.

If you use Secure Sockets Layer (SSL) communication, you can upload your SSL certificate and corresponding key. This action allows the SSL decryptor to decrypt traffic for further analysis. They will automatically assign to your IDS appliances after being uploaded.

For more information, refer to our Alert Logic SSL Decryptor help documentation.

Alert Rules

You can create a collection alert rule in the Alert Logic console to be alerted when your agent or appliance stops collecting, stops sending traffic, or when your appliance policy breaks.

ALERT TYPE

DESCRIPTION

TARGET TYPE: AGENT

Collection

Indicates any issue that has interrupted the collection of network traffic, inclusive of all other availablealerttypes.

Error Status

Reflects an agent health state that requires some triage on behalf of the customer.

Offline Status

May be expected, but if not, it is a condition for which a user may bealerted.

Assignment

Indicates a broken assignment policy error, such as an orphaned agent.

TARGET TYPE: APPLIANCE

Collection

Indicates any issue that has interrupted the collection of network traffic, inclusive of all other availablealerttypes.

Too Many IP Addresses Assigned

Indicates that HOME_NET has run out of room to add more IPs/subnets.

For more information, refer to our Alert Rule help documentation.

Blocking Configuration

Blocking is a feature used within the IDS to prevent an attacker from accessing a host via a specific port, signature type, or host on a firewall. With IDS blocking,a block isonly issued after a threat event has been recognized.

A shun command will be issued to the configured firewall. After the allotted time, Alert Logic threat management will then log back in and issue a no-shun command.

An event-based block is triggered when a particular event is generated. It will be possible for a block to be issued and an incident created for the same traffic.

For more information, visit our knowledge base article.

Browse Devices

A zone is a set of one or more host groups. Alert Logic creates default zones for your account based on your initial configuration discussions. You can add and modify zones to logically group hosts and apply policies in your environment. You can also use zones to limit the information users can view. Zones restrict the collected data that a user account can view. In IDS, the restricted collected data are events. In log, the restricted collected data are log messages.

A host group is a set of one or more hosts. You identify which zone contains the host group and the importance (criticality) of hosts in that host group. You also specify whether assets in that host group contain financial or medical information.

Threat Summary

Overview

Cat is a JSP web shell that hides much of the functionality behind what is a typical web server directory listing HTML interface. Cat was seen used in a campaign against WebLogic servers vulnerable to CVE-2018-2894.

Exploitation

Stages

The attacker sends an HTTP request to create a reverse shell from the server.

Alternatively, an attacker may send an HTTP request to download the file onto the server.

Alternatively, an attacker may send an HTTP request to execute shell commands on the server.

Alternatively, an attacker may send an HTTP request to read and output the contents of a file located on the server.

Alternatively, an attacker may send an HTTP request to download a file from the server.

Alternatively, an attacker may send an HTTP request to write data to a file located on the server.

The server replies with an HTTP 200 OK response and a message indicating that the server was successfully compromised.

Prerequisites

The attacker must be able to send crafted packets to the target system.

Alert Logic Coverage

Alert Logic has evaluated its customer base for exposure to the exploit and has developed signatures for mitigating the threat depending on the security service in place.

The Network-Based Intrusion Detection System (IDS) has been updated with the new signatures for this exploit when detected via Alert Logic Threat Manager. If this signature is detected, an incident is generated in the Alert Logic console.

Recommendations for Mitigation

The attacker must have exploited some other entry vector to allow the malicious files to becomeresident on the victim machine.

In This Article

Overview

Supported Browsers

Getting Started

Create & View Support Tickets

Follow or Unfollow Organization Tickets

View Your Knowledge Base & Community Contributions

Follow Content You Care About

Follow Knowledge Base Sections & Community Topics

Follow Knowledge Base Articles & Community Posts

View & Manage Content You're Following

Access Your User Profile

Overview

The Alert Logic Support Center ( https://support.alertlogic.com ) houses several resources that you can take advantage of when you're in need of support or want to expand your understanding of Alert Logic solutions. This article includes information on submitting support tickets, checking ticket statuses, following Community and Knowledge Base content, accessing your user profile, and more.

Supported Browsers

Please note that the Support Center supports the following browsers:

Desktop

Google Chrome: latest two versions

Mozilla Firefox: latest two versions

Apple Safari: latest two versions

Microsoft Internet Explorer: latest version only

Mobile

Apple Safari: iOS 9 and higher

Google Chrome: latest version

Getting Started

When you arrive at the Support Center home page ( https://support.alertlogic.com ), you will see a number of options to access support information, including Documentation, the Knowledge Base, Training, and Community. Most of the information in the Support Center is available to the public. If you'd like to contribute in the Knowledge Base or Community or access your Support tickets and user profile, you must log in to the Support Center with your Alert Logic product credentials.

To log in to the Support Center, click the SignIn button in the top right corner of the home page. You will be prompted to provide your product log-in credentials. Once logged in, you will have access to all content and functionality within the Support Center!

Training content is available via the LEARN portal To learn more about access, please see the Does Alert Logic offer product training? knowledge base article.

Create & View Support Tickets

If you need to submit a ticket with Alert Logic Support, click on the Create a Ticket button in the top right corner of the Support Center. You will be taken to a web form, in which you can provide the information for your query and submit the ticket to our Support team.

You can access all tickets that you've submitted since June 2016 within the Support Center. Click on the drop-down arrow to the right of your name and profile picture in the top right corner of the page. Choose My activities. Here, you can see all of your submitted tickets, as well as tickets that you are CC'd on and tickets associated with your organization. You can search for specific tickets and filter on current ticket statuses.

Follow or Unfollow Organization Tickets

From the Organization Tickets tab of the My Tickets page, you have the ability to follow all tickets created by anyone within your organization. If you manage several Alert Logic customers, utilize the organization drop-down to choose which organization's tickets you'd like to follow. Once you've chosen your desired organization, click Follow. This will notify you via email of every ticket that is created from or for your organization.

If you've previously opted in to following all of your organization's tickets and would like to opt out, simply click Unfollow and you will stop receiving all of the related tickets.

View Your Knowledge Base & Community Contributions

Anything that you've contributed in the Community or Knowledge Base, including comments and posts, can be accessed by you from the drop-down arrow to the right of your name and profile in the top right corner of the page. Choose My activities, and then choose Contributions from the top bar of tabs.

You can also access this information from your user profile. See the Access Your User Profile section below for more information on your profile.

Follow Content You Care About

When you come across content - be it a Knowledge Base section or article or Community topic or post - you have the option to follow it. Simply click the Follow button next to the section, article, topic, or post. This will opt you in to email notifications on changes and additions to the content you've chosen to follow.

Follow Knowledge Base Sections & Community Topics

When following Knowledge Base sections and Community topics, you have the option to receive email notifications any time a new article/post is addedorany time a new article/post is added AND any time a new comment is added to an article/post in that section/topic.

Utilize the below list of links to easily get to the sections and topics you want to follow:

Knowledge Base Categories

Best Practices

Feature Education

Frequently Asked Questions

How Tos

Security & Software Updates

Cloud Insight Essentials

Compliance

Documentation

Community Topics

Cloud Insight Essentials

Discussions

Feature Requests

Feedback

Improved Log Search

Incident Console General Availability

Questions & Answers

Tips & Tricks

Follow Knowledge Base Articles & Community Posts

You have the option to follow a single Knowledge Base article or Community post. You will receive email notifications when these are updated or comments are added to them.

View & Manage Content You're Following

You can see all of the content that you're following by clicking the drop-down arrow to the right of your name and profile in the top right corner of the page and choosingMy activities. Then chooseFollowing from the top bar of tabs. Here, you can keep track of all the content that you're following. You can also unfollow anything that you no longer wish to receive notifications on.

Access Your User Profile

To access your user profile, click the drop-down arrow to the right of your name and profile picture and chooseMy profile. Your profile shows you all of your activity in the Community and Knowledge Base, as well as how many other users you are following and that are following you.

Your profile can be accessed by other Support Center members and visitors from a contribution of yours, and you can access other members' profiles in the same way.

You can follow another Support Center member from their profile. Simply clickFollowin the top right corner of the user's profile and choose whether you'd like to receive email notifications for new articles and posts or new articles, posts, and comments they contribute.

Is there something you want to see from the Support Center that isn't available today? Drop us a note in the comments - we'd love to hear your feedback. We hope that you'll take advantage of all that the Support Center has to offer!

Alert Logic log management can be configured to collect Amazon Web Services (AWS) VPC flow logs but first you will need to export the AWS CloudWatch logs to an S3 bucket. Instructions on exporting AWS CloudWatch logs to an S3 bucket are available on the Alert Logic public GitHub page.

Once the AWS CloudWatch logs are exported to S3, they can be collected using S3 log sources in the usual way. Thisissupported by the Alert Logic Product Support team. You can find information on configuring S3 log sources for collection within our Log Management Collection Sources documentation.

Note:The Alert Logic public GitHub is made available to customers strictly for informational purposes and is not supported by the Alert Logic Product Support team at this time.

Threat Summary

Overview

There is a vulnerability in the Java JMX server. The vulnerability is due to an insecure deployment, allowing a user to connect to and interact with the service. This can lead to total compromise of the victim server.

Exploitation

Stages

The attacker sends an RMI header.

The server responds with the JMXRMI endpoint.

The attacker proceeds with the handshake with the JMX Bean Server, accessing the vulnerable function javax.management.loading.MLet.

The JMX agent on the victim server accesses the remote URL that is hosting the malicious JAR file on the attacker web server. When the JMX service registers the MLet file, the agent will initiate the URL to the remote JAR and execute the methods leading to code execution.

Prerequisites

The attacker must have direct access to the vulnerable victim host.

Vulnerability Description

There is a vulnerability in the Java JMX server. The JMX service allows users to call the javax.management.loading.MLet function, which permits the loading of an MBean from a remote URL. An attacker can set up their remote web server to host an MLet (text file) that points to a malicious JAR file. When the JMX service registers the MLet file, the agent will initiate the URL to the remote JAR and execute the methods leading to code execution. This can lead to total compromise of the victim server.

Alert Logic Coverage

Alert Logic has evaluated its customer base for exposure to the exploit and has developed signatures for mitigating the threat depending on the security service in place.

The Network-Based Intrusion Detection System (IDS) has been updated with the new signatures for this exploit when detected via Alert Logic Threat Manager. If this signature is detected, an incident is generated in the Alert Logic console.

Recommendations for Mitigation

Update the software to a non-vulnerable version.

Threat Summary

Overview

Shutdown57 is a malicious server-side ransomware application written in PHP. Once the malicious PHP file is uploaded to a web server, it can be accessed and interacted with. By interacting with the web shell, the malicious user is able to cause it to encrypt files on the filesystem within the web server data directory. Currently, other than paying the ransom, there is no known way to decrypt files encrypted by the ransomware.

Exploitation

Stages

The malicious user exploits an attack vector such as outdated software or a misconfigured server to install the web shell.

The malicious user interacts with the web shell and allows the attacker to use web shell functions on the compromised webserver.

A status is returned from the web shell indicating that its usage has been successful.

Prerequisites

The attacker must be able to send crafted packets to the target system.

Alert Logic Coverage

Alert Logic has evaluated its customer base for exposure to the exploit and has developed signatures for mitigating the threat depending on the security service in place.

The Network-Based Intrusion Detection System (IDS) has been updated with the new signatures for this exploit when detected via Alert Logic Threat Manager. If this signature is detected, an incident is generated in the Alert Logic console.

Recommendations for Mitigation

The attacker must have exploited some other entry vector to allow the malicious files to become resident on the victim machine. Ensure that all software is up to date to reduce the attack space for this vector.

Description

The following article describes how to set a false positive scan result from the Alert Logic network intrusion detection system solution to inactive in the Alert Logic console.

A best practice in vulnerability assessment is to set false positive scan results as inactive; thereby removing it from view in the console, as well as from future generated reports. This process allows you to easily identify vulnerabilities that require remediation.

Solution

In the Alert Logic console, click Overview in the main menu and then click Scans in the left sidebar.

On the Scans dashboard, click the Scans tab.

If you manage more than one customer, in the Customer drop-down list, select the customer and then click Go.

Next to the scan that identifies the false positive to mark inactive, click and expand Results.

Next to the date the scan was run, under the Results column, click the hosts link.A list of all hosts and associated vulnerabilities display.

Locate the appropriate host and click the name of the false positive to set inactive.

Click Change Status.

For Change the status of this vulnerability for, select This Host.Note: Do not select All Hosts unless you are certain that the vulnerability in question is a false positive for all hosts in your environment.

Select Inactive.

Click Save.

Additional Information

More information about scanning, ignoring vulnerabilities, and reporting false positives is available in our Scans documentation.

Yes. Alerting frequency thresholds are able to be configured directly in the Alert Logic console for raw events. Incidents are suppressed by analysts in order to avoid duplicate notifications.

Description

Selectingthe bestAlert Logicdeployment method for your security needs is crucial for both cost-effectiveness and longevity of the Alert Logic service. Alert Logichasa wide range of providers to ensure that you have thebestoptions foryourdeployments to be implemented.

Deployment Methods

The following deployment methods are offered by Alert Logic. Select the appropriatedeployment type based on which environment you are on:

On-Premise Physical

Where you have a physical environment already in place that you can utilize to send threat traffic toAlert Logic

Where certain compliance dictates that you have physical access to the threat manager

Sending threat traffic to the threat manager via physical connection (SPAN)

VMware Based OVA Threat Manager

Where you have the underlying physical infrastructure and compute power to haveAlert Logicrun on

Where you are already licensed for a full VMware based deployment

When you intend on running the Alert Logic agent on hosts to send threat traffic to the threat manager

Amazon Web Services(AWS)EC2 Instances

Where you lack thesufficientphysical hardware to either install the threat manager on or have little to no physical infrastructure to send data to the threat manager

Where the environment is dynamically changing on a semi-consistent basis and above to provision additional resources as required

When you intend on running the Alert Logic agent on hosts to send their threat traffic to the threat manager

When you want to avoid the up-front costs of purchasing a physical infrastructure

Azure Virtual Machines/Google Cloud Platform Compute Instances

Same points as AWS;all three are cloud vendors with similar offerings. However, AWS is the more mature platform and has the better overall virtual machine deployment methods.

If the cost for either of these deployment methods is cheaper than AWS for your use case, then thatisyour best argument for choosing one of these platforms over AWS.

In a constantly changing environment, youshould typicallypick one of thecloudvendors, but in a more static environment, any of the above can apply.

In This Article

Overview

Network Intrusion Detection

SSL/TLS Session Key

Why the Network IDS Does Not Support Diffie-Hellman

How to Find Out if a Server Supports Diffie-Hellman

The Math Behind Diffie-Hellman

Overview

The Alert Logic network intrusion detection system (IDS) does not support Diffie-Hellman. To explain why we do not use Diffie-Hellman, it is necessary to discuss the elements involved and describe how Diffie-Hellman secures communication between two parties. This article also details the math supporting Diffie-Hellman.

Network Intrusion Detection

The network IDS has the capability to decrypt and inspect HTTPS/TLS traffic for connection endpoints (servers) within the customer's environment. This capability does not inspect traffic from clients inside the environment to endpoints outside the customer's environment, such as when desktop users connect to external secure websites. This type of traffic inspection is outside the scope of an IDS solution and is often done by HTTPS/TLS inspection solutions that insert themselves as an inline middleman (proxy) between clients and servers.

SSL/TLS Session Key

In the context of SSL/TLS, a session key is an ephemeral key used to encrypt and decrypt traffic that is sent over an SSL/TLS connection.

Most key agreement protocols, like the RSA protocol, work by sharing the session key by sending it from one party to the other over the network. The session key is encrypted with the public key of the server and can only be decrypted with the server private key. Anything that has the private key can decrypt the session key and use it to decrypt the rest of the traffic that is part of the session. Therefore, having the certificate and private key for a server allows the network IDS and web application IDS to inspect SSL/TLS traffic.

Why the Network IDS Does Not Support Diffie-Hellman

The Diffie-Hellman key agreement protocol, however, does not share the session key nor does it share all the values needed to compute the session key. Instead, it relies on a special mathematical relationship among several shared values and some secret (unshared) values that allows each party to independently compute the session key. This is what allows Diffie-Hellman to provide perfect forward secrecy and prevent man-in-the-middle attacks. So even if a third-party has the private key and inspects all the values shared between the client and server, it will not have all the values needed to compute the session key, and therefore will not be able to decrypt the traffic sent during the session.

This is why Diffie-Hellman is not supported as a key exchange protocol for the network IDS and web application IDS or any other solution that needs to passively inspect encrypted traffic. For a solution to be able to decrypt traffic that is using Diffie-Hellman, the solution would need to intercept and terminate the connection handshake and act as a middleman or proxy. This is what HTTPS inspection tools do. But the network IDS is not an inline solution, so it does not intercept connections.

Diffie-Hellman is the most secure key exchanged protocol and as such, it will generally be enabled by default. It may seem a bit ironic that Alert Logic solutions require the use of less robust protocols so that they can perform their function of detecting threats, but the trade-off is considered justified. The benefit of being able to inspect and detect threats in encrypted traffic outweighs any possible downsides to not using Diffie-Hellman.

How to Find Out if a Server Supports Diffie-Hellman

One way to see if a server or endpoint supports Diffie-Hellman is to use the nmap tool with the option for the ssl-enum-ciphers script, as shown in the example below, to list all supported cipher suites. All cipher suites that list DH, DHE, or ECDHE use Diffie-Hellman.

nmap --script ssl-enum-ciphers -p <port> <IP address/hostname>

Example

$ nmap --script ssl-enum-ciphers -p44310.54.42.11

Starting Nmap7.31( https://nmap.org ) at 2017-01-19 14:53 CST

Nmap scan reportfor10.54.42.11

Host is up (0.00058s latency).

PORT STATE SERVICE

443/tcp open https

| ssl-enum-ciphers:

| TLSv1.0:

| ciphers:

| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A

| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A

| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh1024) - A

| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh1024) - A

| TLS_RSA_WITH_AES_256_CBC_SHA (rsa2048) - A

| TLS_RSA_WITH_AES_128_CBC_SHA (rsa2048) - A

| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa2048) - C

| TLS_RSA_WITH_RC4_128_SHA (rsa2048) - C

| TLS_RSA_WITH_RC4_128_MD5 (rsa2048) - C

| compressors:

| NULL

| cipher preference: server

| warnings:

|64-bit block cipher 3DES vulnerable to SWEET32 attack

| Broken cipher RC4 is deprecated by RFC7465

| Ciphersuite uses MD5formessage integrity

| Key exchange (dh1024) of lower strength than certificate key

|_ least strength: C

MAC Address:12:34:56:78:9A:BC (Unknown)

Nmap done:1IP address (1host up) scanned in0.45seconds

The Math Behind Diffie-Hellman

The following is the math that is used by the Diffie-Hellman key exchange protocol to calculate a key. This shows that the two values needed (c and d) to calculate the key are never shared; therefore, the protocol is not susceptible to a man-in-the-middle intercepting the key or all the values needed to calculate it.

Alice picks two prime numbers g and p and shares them with Bob. Alice then picks a secret number c and calculates A = gc mod p. And Alice shares the number A with Bob. Bob then picks his own secret number d and calculates B = gd mod p. And Bob shares the number B with Alice.

Alice takes B and calculates kA = Bc mod p. And Bob takes A and calculates kB = Ad mod p.

A = gc mod p B = gd mod p kA = Bc mod p kB = Ad mod p

Since B = gd mod p Bc mod p = gdc mod p

Since A = gc mod p Ad mod p = gcd mod p

Therefore, kA = kB

Any third party observer will be unable to derive the shared key.

Overview

The Alert Logic network intrusion detection system (IDS) offers reporting capabilities for security metrics and compliance that customers can take advantage of. Find the available reports in the Alert Logic console by clicking Reports from the main menu. Graphical representations, primarily pie charts and bar graphs, are used in executive and CIO-level reports. The following article describes the network IDS reporting capabilities.

Standard Reports

The Alert Logic network IDS includes a series of static reports which highlight statistics on the key security metrics that we collect, such as incidents, events, and vulnerabilities. Reports can be configured to highlight time and per host statistics. In addition, static compliance reports are available for HIPAA, SOX, PCI, and GLBA.

Exporting Reports

All reports can be created and run on an ad-hoc basis. Reports can be accessed via the Alert Logic console and can be exported via PDF or Excel/CSV. Reports may also be emailed oncethey'rebeen generated. You can schedule reports to run on an automatically recurring basis.

Automated Compliance Reports

Predefined compliance reports are available in the Alert Logic console, and include, but are not limited to: CIO Threat Report, CIO Threat Trend Report, Blocked Hosts Report, Users Actions Log, Incident Report, FFIEC, PCI, SOX, GLBA, and HIPAA.

Overview

Starting on November 14, 2018, several new reports and a new Reports menu will be available in the Alert Logic console. With this release, 10 new reports are available to help you assess incidents, web application firewall (WAF) traffic, vulnerabilities, remediations, and more. In addition, current and new reports have been reorganized into new submenus under the Reports menu in the Alert Logic console. Read on to learn more about the new reports and where to access previous reports in the new submenus.

Security Remediation Trends

New Reports

There are 10 new reports available in the Alert Logic console. The following new reports may be available for your subscription to Alert Logic solutions.

Incident Workflow Explorer This report is available in the new Threats submenu in the Incident Analysis report group for customers using Alert Logic Threat Manager, Log Manager, Web Security Manager, and/or Cloud Defender.

WAF Violation Explorer This report is available in the Threats submenu in the Web Application Analysis report group for customers using Alert Logic Web Security Manager Premier.

WAF Traffic This report is available in the Service submenu in the Capability Usage report group for customers using Web Security Manager Premier.

Vulnerability Summary This report is available in the Vulnerability submenu in the Vulnerability Analysis report group for customers using Alert Logic Cloud Insight.

Vulnerable Host Explorer This report is available in the Vulnerability submenu in the Vulnerability Analysis report group for customers using Cloud Insight.

Vulnerability Distribution Explorer This report is available in the Vulnerability submenu in the Vulnerability Analysis report group for customers using Cloud Insight.

Configuration Remediation Trends This report is available in the Remediations submenu in the Configuration Remediations report group for customers using Cloud Insight.

This report is available in the Remediations submenu in the Security Remediations report group for customers using Cloud Insight.

PCI Requirement 6.6 This report is available in the Compliance submenu in the PCI Audit report group for customers using Alert Logic Cloud Defender, Web Security Manager, and/or Web Security Manager Premier.

PCI Requirement 10.6 This report is available in the Compliance submenu in the PCI report group for customers using Cloud Defender, Log Manager, and/or Log Review.

In addition, new and current reports provide the ability to filter by the parent or child account(s). Using the Customer Account field at the top of the report, you can select the account for which you want to review report data.

New Reports Menus

The new and current reports have been organized into a new series of submenus under the Reports menu in the Alert Logic console. For the new reports, the submenu for each new report is listed above.

For current reports, use the following table to locate your commonly used reports in the new submenus. Some current reports have been replaced and renamed with these updates.

Previous Submenu

Previous Report Group

Previous Report Name

New Submenu

New Report Group

Interactive

Service Review

Monthly Service Review

Service

Capability Usage

Interactive

Service Review

Customer Contacts

Service

Users

Interactive

Incident Analysis

Incident Daily Digest

Threats

Incident Analysis

Interactive

Incident Analysis

Incident Daily Digest Trends

Threats

Incident Analysis

Interactive

Incident Analysis

Incident Distribution Explorer

Threats

Incident Analysis

Interactive

Incident Analysis

Incident Target Explorer

Threats

Incident Analysis

Interactive

Incident Analysis

Incident Attacker Explorer

Threats

Incident Analysis

Interactive

AWS Incident Analysis

AWS Risk Summary

Risk

Threat Risk Index

Interactive

AWS Incident Analysis

AWS Incident Daily Digest

Threats

AWS Incident Analysis

Interactive

AWS Incident Analysis

AWS Incident Daily Digest Trends

Incident Analysis

AWS Incident Analysis

Interactive

AWS Incident Analysis

AWS Incident Distribution Explorer

Threats

AWS Incident Analysis

Interactive

AWS Incident Analysis

AWS Targeted Deployment Explorer

Threats

AWS Incident Analysis

Interactive

AWS Incident Analysis

AWS Targeted Deployment Trends

Threats

AWS Incident Analysis

Interactive

Azure Incident Analysis

Azure Incident Daily Digest

Threats

Azure Incident Analysis

Interactive

Azure Incident Analysis

Azure Incident Daily Digest Trends

Threats

Azure Incident Analysis

Interactive

Azure Incident Analysis

Azure Incident Distribution Explorer

Threats

Azure Incident Analysis

Interactive

Azure Incident Analysis

Azure Targeted Deployment Explorer

Threats

Azure Incident Analysis

Interactive

Azure Incident Analysis

Azure Targeted Deployment Trends

Threats

Azure Incident Analysis

Interactive

CIS Benchmarks

CIS AWS Foundations Benchmark

Compliance

CIS Benchmarks

Interactive

PCI Audit

PCI Requirement 6.6

Compliance

PCI Audit

Interactive

PCI Audit

PCI Requirement 10.6

Compliance

PCI Audit

Interactive

Environment Exposure Trends

Exposure Assessment Trends

Vulnerabilities

Vulnerability Analysis (report also renamed to AWS Exposure Assessment Trend)

Interactive

Environment Exposure Trends

Severity Trends

Replaced by new Vulnerable Host Explorer in Vulnerabilities submenu

Interactive

Vulnerability Analysis

Vulnerability Explorer

Replaced by new Vulnerability Summary in Vulnerabilities submenu

Interactive

Vulnerability Analysis

Vulnerable Host Explorer

Vulnerabilities

Vulnerability Analysis (report also renamed to AWS Vulnerable Host Explorer)

Interactive

Vulnerability Reports

List of Vulnerabilities

Vulnerabilities

Vulnerability List

Interactive

Product Usage

Deployments Usage by Day

Service

Cloud Insight

Interactive

Product Usage

Host Usage by Day

Service

Cloud Insight

Interactive

Product Usage

Host Usage by Hour

Service

Cloud Insight

Scheduled

ALL

All reports still in Scheduled submenu

WAF

ALL

All reports still in WAF submenu

Usage

ALL

All reports still in Usage submenu

Note: With these changes, the URLs for the current reports have changed. Any bookmarks created for report pages in the Alert Logic console will need to be updated with the new locations.

For customers using Alert Logic solutions who want to encrypt their traffic, only certain ciphers are allowed. Some ciphers are not allowed as they are vulnerable to attack.

Alert Logic accepts the following ciphers to encrypt traffic:

AES256-GCM-SHA384

AES256-SHA256

AES256-SHA

AES128-GCM-SHA256

AES128-SHA256

AES128-SHA

Note: This article includes information for customers who subscribe to Alert Logic Log Manager. For more information on Amazon Web Services (AWS) CloudTrail collection for Alert Logic SIEMless Threat Management, refer to our About AWS Cloud Trail and Alert Logic documentation.

In order to get Alert Logic to begin collecting Amazon Web Services (AWS) CloudTrail logs within the Alert Logic console, you must complete two stages of action.

The first stage is setting up AWS CloudTrail, which includes enabling CloudTrail, creating an SQS Queue, creating an IAM Policy, and creating an IAM role. Details on completing all of these actions can be found within our Log Manager for AWS CloudTrail documentation.The second stage is setting up the source in the Alert Logic console.

Note:You will need to enable a cross-account policy and role before setting up a CloudTrail log source. Details on this can be found within our Configure Alert Logic Cloud Defender AWS Cross-Account Role Access documentation.

There are no specific infrastructure requirements associated with having theAlert Logic Log Management functionalityactive. The limited footprint of infrastructure forthe customer includes agents, virtual appliances, physical appliances, or remote collectors. The only requirement associated withcollection is the ability to collectlogs via Windows Event Viewer/channels, flat file, or syslog.

No. In fact, new user accounts can, and are encouraged to, be created by customers who have been designated as Administrator within the Alert Logic console.When a company first signs up for Alert Logic services, they are asked to designate an Administrator user for the Alert Logic console, which Alert Logic will create. It is up to the Administrator to generate and maintain the other user accounts for access to the console. Alert Logic has no way of knowing when employees come and go from your company, nor what level of access each person requires to fulfill their job responsibilities, so it is not possible for Alert Logic to maintain users for your account.

Alert Logic Web Security Manager is the passive, out-of-band web application IDS, while Alert Logic Web SecurityManagerPremier is the inline, preventative web application firewall (WAF). They use the same technology to identify malicious requests negative security HTTP/HTTPS signatures for known attacks based on the OWASP Top 10 and a positive security model that uses a learning engine to create policies for known, valid input. Web Security Manager Premier provides active blocking of bad requests with a log of what has been blocked, whereas Web Security Manager identifies bad requests, which are aggregated and analyzed to generate incidents triaged through the Alert Logic ActiveWatch team.

Web Security Manager is deployed as a module with Alert Logic Threat Manager or Alert Logic Cloud Defender, and traffic ishandledvia agent or span port.

Web Security Manager Premier is a standalone product that can be run in the cloud as a virtual machine or as a hardware appliance. Traffic is routed directly to the inline WAF in either a routed or reverse proxy mode.

It is important to understandthe relationship between parent and child accountsto understand how users are provided access to account data.Consider the following example:

Account A as the parent account

Account Bas the child account ofAccount A

Account C as the child account of Account B (sometimes referred to as child of child account or grandchild account)

If a user account is created at Account A (parent account level), the user will have access to both Account B and Account C.

If a user account is created in Account B (child account level), then the user will have access to Account C but will not have access to Account A, regardless of what role has been applied.

If a user account is created in Account C (child of child/grandchild account level), then the user will only have access to Account C. Account A and Account B are off-limits to this account hierarchically.

For more information about managing accountsand users,refer to our Customer Accounts, User Accounts, and User Roles documentation.

Overview

Customers who use the Alert Logic Threat Manager network intrusion detection system (IDS) and web application IDS may need to upload SSL/TLS keys and certificates to have encrypted traffic inspected. This decryption process requires that these keys and certificates be uploaded through the Alert Logic console. In both cases, the data is encrypted in transit and at rest.

Note: This article speaks specifically to how this data is protected on the appliance.

Securing SSL Keys and Certificates

For Alert Logic network IDS and web application IDS features, customers have the option to upload important information to the appliance through the Alert Logic console. In this case, you may want to decrypt currently encrypted traffic present within a deployment for proper inspection. To accomplish this, you can upload the relevant SSL keys and certificates for the environment that is being protected.

In order to ensure that data is protected, Alert Logic encrypts the data on the appliance and in the back end, where it is also stored. The method of securing this information differs between the two features:

Web Application IDS

For the web application IDS, customer SSL/TLS keys and certificates are converted to PKCS#8 and encrypted using AES-256. Encryption occurs via a secret derived from a key used to encrypt Alert Logic Web Security Manager software, as well as some of the certificate data. These are salted, and thus the same keypair uploaded multiple times will never have the same encryption secret.

The secret is computed when the keys are loaded into the proxy engine and is then erased from memory - it is never stored anywhere on the appliance. Alert Logic only stores the PKCS#8 key with the encrypted payload.

Network IDS

The use of encryption keys and certificates for the network IDS application is conceptually similar to that of the web application IDS, except that the binary configuration file is encrypted using either the agent certificate's private key or a separate key derived from the agent host's identity before being stored to disk. Cryptographic Message Syntax - formerly PKCS#7 - EnvelopedData messages, which are also used in Secure/Multipurpose Internet Mail Extensions, are utilized when encrypting these IDS configurations.

Note: Alert Logic utilizes different encryption methods for these two products because their data are stored using methods unique to each application.

Overview

Alert Logic SIEMless Threat Management utilizes discovery scans to identify hosts and other assets in data center deployments, where no other data sources, like cloud APIs, provide asset information. When a physical or virtual Alert Logic appliance is installed in a data center deployment, the appliance will periodically scan the local network using discovery scans. If multiple network address blocks (CIDR ranges) are associated with the network, each block will be scanned separately. The scheduling of discovery scans can be configured in theDeployments>Configuration section of the Alert Logic console.

Discovery Scanning

During a discovery scan, the following actions occur for each individual address in each network block:

An ICMP echo (ping) request is sent. If no answer is received on the first attempt, another ICMP ping is sent.

An ICMP timestamp request is sent.

A "TCP ping" is sent to 22 commonly used UCP ports (21, 22, 23,25, 53, 80, 110, 111, 135, 139, 143, 443, 445, 993, 995, 1723, 3306, 3389, 5900, 8080, 8400, 49154). TCP pings use a deviation of the TCP standard three-way handshake to determine if a machine responds. This method sends an unsolicited TCP Synchronize (TCP SYN) to the specified port. If an active machine is listening on this port, it should send back a reset to the unsolicited request.

The 12 most common UDP ports are tested for response (ports 53, 69, 111, 123, 137, 138, 161, 177, 445, 500, 1900, 4500).

An IP that responds to any of the above checks is considered discovered. Each discovered IP is compared with the IP addresses of hosts in the network where the discovery scan was made.

If that IP address is already present for a host asset in the network, the last discovery time of the host is set to the current time.

Otherwise, a new host asset is created with the IP address, and the last discovery time of the host is set to the current time.

Discovery Scan & Agents

When an Alert Logic agent is installed on a host, the host's networking configuration is transmitted to Alert Logic. That data is used to create host asset records, and any host previously discovered by a discovery scan will be replaced by a single host with all the local IP addresses.

Example

On Monday, new host prodWebserver was started in a protected network. The host has two local IP addresses: 10.0.0.10 and 10.0.0.11. That day, those two IP addresses are discovered for the first time. Two hosts are created, one with each IP address. On Tuesday, the Alert Logic agent is installed on prodWebserver. The two existing hosts are replaced by a single host with name prodWebserver and two local IP addresses, 10.0.0.10 and 10.0.0.11.

In this example, the installation of the Alert Logic agent provided better information about the host, prodWebserver. For this reason, the installation of the Alert Logic agent is highly recommended wherever feasible. The list of known hosts with no agent installed is available in the Health Console within the Alert Logic console.

Expiration of Discovered Hosts

Periodically, hosts in data center networks are examined to delete hosts that have not been recently discovered. Hosts that have not been seen in a discovery scan for seven days (168 hours) and have no Alert Logic agent installed will be deleted.

Overview

Two new service reports - Current Users and User Login Trends - have been added to the Alert Logic console. They can be found at Reports > Service > Users and are available to all customers. These reports provide more detailed visibility into provisioned users and their usage trends.

Current Users Report

The Current Users report provides a visual overview of the users in your account. Benefits of utilizing this report include:

Visibility into users provisioned in the Alert Logic console

Confirmation that users no longer requiring access have successfully been removed

Ability to determine which users are assigned specific user roles

Verification of last login and password reset

For technical details on the Current Users report, see the Current Users documentation.

User Login Trends Report

The User Login Trends report provides a visual overview and a list of the users who log into the Alert Logic console. Benefits of utilizing this report include:

Visibility into which users are logging directly into the Alert Logic console vs. via API

Ability to evaluate how often and when users log in

Identification of login patterns or anomalies within a selected month

For technical details on the User Login Trends report, see the User Login Trends documentation.

Description

If you have identified that one of your Amazon Web Services (AWS) instances has been compromised, you need to contain the threat, restore service, determine, and remediate the root cause. The capabilities in AWS give you some specific options to help with containment. In AWS, there are multiple ways to respond to this incident.

To contain, you may choose to quarantine, stop, and/or terminate the instance.

Method 1 - Quarantine the Instance

By quarantining an instance, you can prevent future harm while leaving the instance running to allow for an investigation into the cause of the compromise.

Considerations

Before performing the steps to quarantine the instance, you need to determine if the instance is part of an Auto Scaling group or attached to a load balancer. If the instance was created by Auto Scaling, you must first detach the instance from the Auto Scaling group to prevent it from being terminated by the Auto Scaling service due to failing health checks once it has been quarantined.

For an instance attached to an Elastic Load Balancer, you will need to deregister it from the Elastic Load Balancer to prevent the Elastic Load Balance from attempting to send it further requests. If the instance is part of a target group associated with a Network Load Balancer or Application Load Balancer, you will need to delete the instance from the target group.

Performing the Quarantine

Once the above steps are completed, you can quarantine the compromised instance by changing the security groups associated with all the instances Elastic Network Interfaces (ENIs) to a security group that has no allow rules for either ingress or egress and thus will deny all traffic in or out of the instance.

IMPORTANT: Be sure that you create a new security group to apply to the instance. DO NOT modify the existing security group as that will affect other instances. Also be sure to remove the default Allow All rule for egress on the new security group used to quarantine the instance.

At this point, the malware will be unable to spread, but it may still be actively working on the system, encrypting data for ransom, searching for sensitive information to exfiltrate, probing the security group for an open outbound port, or possibly self-destructing.

Once the instance has been quarantined, perform forensic analysis to determine the root cause of the compromise. Only security experts should investigate the root cause of a compromise; otherwise, valuable forensic data could be inadvertently lost, or the threat could spread.

When your incident response team is ready to investigate, you can change the security group to allow inbound SSH and RDP from an instance. The statefulness of security groups will allow you to connect to the instance without allowing any egress rules on the affected host.

If you are concerned about the effects of some malware (ransomware) on an instance, you can stop the instance.

Method 2 - Stop the Instance

If you want to stop malware activities once the instance has been isolated, or take a snapshot to send to forensic investigators, you should stop the instance and take an offline Amazon EBS snapshot of the root EBS volume and any other volumes that may contain information needed as part of the investigation. Forensic investigators can determine the root cause, the impact of the compromise, and the remediation required to prevent it in the future.

If the instance is using an instance-store AMI, you cannot stop the instance. You should consider quarantining the instance with a security group instead to make sure no data is lost or terminating the instance.

Method 3 - Terminate the Instance

If you will not be performing in-depth forensics, you may always terminate the instance. However, until security experts perform a root cause analysis and remediate the issue, this instance and other instances will continue to be compromised.

Once you have contained the threat, you can launch a new instance of the same type or launch a snapshot from before the compromise occurred. Once you have determined a root cause, you should update your AMI to include any needed patches or configuration changes and ensure that the vulnerable AMI is not referenced by any Auto Scaling groups or automation tools.

Still have questions? Check out other customers posts or add your own in the Cloud Insight Essentials community.

Description

If you were notified of suspicious user behavior and believe that an Amazon Web Services (AWS) account has been compromised, consider the following steps:

Change your AWS root account password or the passwords of IAM users.

Delete or rotate AWS access keys of the affected account.

Delete any resources created by the compromised account, especially running EC2 instances, EC2 spot bids, or IAM users.

Review/confirm recent user activities.

Review user permissions in the AWS console.

Read on for additional information about each solution.

Solution 1 - Change Passwords

If the root AWS account was compromised, change your AWS root account password and the passwords of any IAM users for whom the root account reset the password, using CloudTrail to review for password resets. If another IAM user's account was compromised, change that account password.

To change your root AWS password, refer to AWS documentation on How do I change the password associated with my AWS account? For information on changing the password of an IAM user, refer to AWS documentation on Managing Passwords for IAM Users.

It is strongly recommended to protect your root account with multi-factor authentication using a hardware key. Its a best practice to change your passwords on a regular basis to avoid unauthorized use of your account. For information on AWS security best practices, refer to the whitepaper at AWS Security Best Practices.

Solution 2 - Disable, Delete, or Rotate Access Keys

If your application access key has been compromised, replace the compromised key with a new one. Create a new key, modify your application, and disable (but do not delete) the first key. If there are any problems with your application using the new key, reactivate the first key temporarily. When your application is fully functional with the first key in the disabled state, delete the first key.

Treat AWS access keys the same way you would treat an account passworddo not provide access keys to anyone you do not know and trust, do not publish access keys to public websites or code repositories, and consider best practices when using or managing AWS access keys. You might also consider using IAM roles for EC2 instances, or using STS to generate temporary credentials.

If you find AWS access keys that you no longer need or did not create, consider deleting them.

Solution 3 - Delete Unrecognized or Unauthorized Resources

Sign in to your AWS account and check that all resources currently running on your account are resources you launched. Make sure to check all AWS regions, even regions in which you have never launched AWS resources. Pay special attention to running EC2 instances, EC2 spot bids, or IAM users. If you are not sure how to delete a resource associated with a particular AWS service, find the documentation related to that service at AWS Documentation.

Solution 4 - Review User Activities

Review CloudTrail logs for other activities by the potentially compromised user. You can review seven days of CloudTrail messages in the AWS console or Log Management customers have access to a year (by default) of CloudTrail messages in the Alert Logic console.

Solution 5 - Review Permissions

Limit future impact from compromised user accounts by auditing user, group, and role permissions for opportunities to restrict the permissions. For instance, only authorized users should be able to change password policy requirements. Allowing any user to change this could cause your business to fail a compliance audit.

You may also want to check your remediations in the Alert Logic console for users that have overly permissive IAM policies. To check remediations for users, navigate to Remediations > List and use the Refine By section to filter the list to a specific user. Review the list of remediations for the user and address remediations for that user as needed.

Threat Summary

Overview

The Accesson.php web shell is a simple web shell with two main functions: execution of PHP code and arbitrary file upload. After the attacker has successfully uploaded the web shell to the target system, they can execute PHP code via scripted commands to the shell. This lightweight shell has been observed to be used to upload more robust shells with more functionality.

Exploitation

Stages

A remote, unauthenticated attacker uploads the Accesson web shell to a vulnerable server.

The server responds successfully indicating that the shell has been uploaded.

The attacker can either execute PHP code via the id parameter or upload files via the up parameter.

Prerequisites

The attacker must have exploited some other entry vector to allow the malicious files to becomeresident on the victim machine.

Alert Logic Coverage

Alert Logic has evaluated its customer base for exposure to the exploit and has developed signatures for mitigating the threat depending on the security service in place.

The Network-Based Intrusion Detection System (IDS) has been updated with the new signatures for this exploit when detected via Alert Logic Threat Manager. If this signature is detected, an incident is generated in the Alert Logic console.

Recommendations for Mitigation

Ensure that all internet-facing hosts have the most up-to-date patches applied.

Threat Summary

Overview

Sodinokibiis an evasive ransomware that makes use of packing, obfuscation, local privilege escalation exploits,and network obfuscation to hide its execution and C2 traffic. The ransomware targets document files and demands a ransom to be paid via TOR.

Exploitation

Stages

An attacker places the malware on a target host through social engineering or exploiting some other vulnerability.

The ransomware is either attacker oruser-triggered. Once executed, it escalates privileges, targets documents for encryption, drops a ransom note, and calls out to an external C2 server.

Prerequisites

The attacker must have exploited some other entry vector to gain access to the local victim host.

Alert Logic Coverage

Alert Logic has evaluated its customer base for exposure to the exploit and has developed signatures for mitigating the threat depending on the security service in place.

The Network-Based Intrusion Detection System (IDS) has been updated with the new signatures for this exploit when detected via Alert Logic Threat Manager. If this signature is detected, an incident is generated in the Alert Logic console.

Detection of this threat is provided via theAlert LogicActiveWatchfor Log Manager service. Log messages are produced by the vulnerable system when an exploit of this type is leveraged. An incident will be generated in the Alert Logic console if these log messages are observed.

Recommendations for Mitigation

The attacker must have exploited some other entry vector to gain access to the local victim host. Ensure that all software on internet-facing hosts isup-to-date.

Threat Summary

Overview

The PS PHP web shell is a lightweight web shell that receives and executes OS commands. This shell could be used as an initial dropper before establishing persistence with a larger web shell or by exfiltrating credentials for another service such as SSH.

Exploitation

Stages

An attacker uploads a shell to a vulnerable or misconfigured system.

The attacker attempts to access web shell functionality to carry out objectives.

The web shell responds with the output from the command.

Prerequisites

The attacker must be able to send crafted packets to the target system.

Alert Logic Coverage

Alert Logic has evaluated its customer base for exposure to the exploit and has developed signatures for mitigating the threat depending on the security service in place.

The Network-Based Intrusion Detection System (IDS) has been updated with the new signatures for this exploit when detected via Alert Logic Threat Manager. If this signature is detected, an incident is generated in the Alert Logic console.

Recommendations for Mitigation

The attacker must have exploited some other entry vector to gain access to the local victim host. Ensure that all software on internet-facing hosts is up-to-date.

Threat Summary

Overview

PAExec is a remote administration tool designed as an alternative to psexec. The tool is a small remote shell that includes functionality for copying files, remote execution, and fully interactive shell sessions with remote Windows machines without the need to install client software. The functionality offered by the PAExec tool is perfect for conducting Post Compromise activity once a foothold has been established.

Exploitation

Stages

An attacker compromises a Windows system and gains a foothold.

The attacker uses the PAExec tool to move laterally using compromised credentials.

Prerequisites

The attacker will compromise a Windows server and gain administrator credentials for the target system.

Alert Logic Coverage

Alert Logic has evaluated its customer base for exposure to the exploit and has developed signatures for mitigating the threat depending on the security service in place.

The Network-Based Intrusion Detection System (IDS) has been updated with the new signatures for this exploit when detected via Alert Logic Threat Manager. If this signature is detected, an incident is generated in the Alert Logic console.

Detection of this threat is provided via the Alert Logic ActiveWatch for Log Manager service. Log messages are produced by the vulnerable system when an exploit of this type is leveraged. An incident will be generated in the Alert Logic console if these log messages are observed.

Recommendations for Mitigation

The attacker must have exploited some other entry vector to gain access to the local victim host. Ensure that all software on internet-facing hosts is up-to-date.

Threat Summary

Overview

A stored cross-site scripting vulnerability exists in versions <= 1.4.11 of the WordPress Plugin Simple Fields. A specially crafted POST request can be made that injects scripts into the functionality of new WordPress Posts and Pages function as well as Simple Fields administrative settings. This occurs because the user-provided input does not go through any filtering/sanitization and the function that allows the admin-post does not authenticate the user. The plugin is currently removed from the WordPress download page.

Exploitation

Stages

An attacker makes a POST request to a specific method in the program that decodes a JSON payload and sets variables that will later be manifested in the DOM.

The attacker will receive a 302 Found and no error messages, and the payload is now stored in the WordPress instance Options.

Prerequisites

The attacker must be able to send crafted packets to the target system.

Alert Logic Coverage

Alert Logic has evaluated its customer base for exposure to the exploit and has developed signatures for mitigating the threat depending on the security service in place.

The Network-Based Intrusion Detection System (IDS) has been updated with the new signatures for this exploit when detected via Alert Logic Threat Manager. If this signature is detected, an incident is generated in the Alert Logic console.

Recommendations for Mitigation

The Options table must be cleaned even after the plugin is uninstalled to ensure no further versions will pull the same information. Ensure that all software on internet-facing hosts is up-to-date.