MCP Security Best Practices¶

Cryptography introduction¶

You can employ encryption for protecting network traffic, secrets, and ordinary data at rest. Consider the following recommendations stated in the NIST standard for choosing appropriate cipher suites and key management techniques:

• For storing passwords, always use a salt. A salt should be unique for every stored password and randomly generated.

• For symmetric encryption with passphrases, use a passphrase with appropriate entropy valid for particular cipher key strength and expected brute-force durability. For example, a valid passphrase for 128 bit cipher (CAST-5, AES-128) should contain at least 128 bits of entropy.

• Whenever possible, use ephemeral keys to maintain forward secrecy. Use Diffie-Hellman for exchanging keys.

• Whenever possible, use Elliptic Curve Cryptography (ECC) as it requires less computational power than RSA or DSA.

• To protect sensitive data (encrypting and digitally signing) in a long perspective (2031 year and beyond), use cipher suites and key length with security strength 128 or more (192, 256).

  Note

  The finite-field cryptography (FFC) and integer-factorization cryptography (IFC) algorithms with higher security strength of 192 and 256 bits are not currently included in the NIST standards for interoperability and efficiency reasons.

• Use the algorithms that have security strength of 128 bits that are secure and efficient at the same time. To protect data until 2030, you can use cipher suites and key length with the security strength of 112 bits.

where L - is the size of the public key, N - is the size of the private key.

MCP OpenStack cryptography considerations¶

To provide for confidentiality and integrity of network traffic inside your OpenStack deployment, Mirantis recommends using cryptographic protective measures, such as the Transport Layer Security (TLS) protocol. MCP provides solutions for various TLS encryption use cases. The most common ones are described below.

By default, only the traffic that is transmitted over public networks is encrypted. However, cryptography support, TLS encryption, and optionally X.509-based certificate authentication is also available for the MCP management plane services like MySQL, RabbitMQ, libvirt control channel and live migration data channel, and libvirt NoVNC proxy.

When deploying an MCP OpenStack environment, consider enabling cryptographic measures to better protect the MCP cluster from eavesdropping and public to control plane attacks:

• MCP Deployment Guide: Enable TLS for cluster internal API HTTP transport
• MCP Deployment Guide: Enable TLS for RabbitMQ and MySQL server-server communications
• MCP Deployment Guide: Enable TLS for RabbitMQ and MySQL client-server communications
• MCP Deployment Guide: Enable TLS for Libvirt control channel and live migration data
• MCP Deployment Guide: Enable TLS for Libvirt VNC to NoVNC clients (since Queens release)
• MCP Deployment Guide: Enable encryption for Memcached

Mandatory access control¶

Use Linux mandatory access control (MAC) enhancements to mitigate EoP threat. SELinux, AppArmor, and grsecurity are possible MAC security enhancements for Linux. The choice of a Linux security enhancement may depend on your personal experience and type of a host OS distribution.

Rootwrap¶

Rootwrap is a security wrapper designed to allow a service-specific unprivileged user to run a number of actions as the root user in the safest manner possible mitigating EoP such as when an attacker takes advantage of a running service with root privileges. The rootwrap.conf file contains filter definition directories and specifies command filters to be loaded for them. Since the configuration file is in the trusted security path, it needs to be owned and writeable only by the root user to avoid tampering. On a host Linux machine, enable encryption for a home directory when creating a privileged user to mitigate information disclosure threat.

For example, on Ubuntu use the following command:

adduser --encrypt-home

You might want to encrypt not the whole Home directory but only a specific folder of files. In such case you can use the ~/.Private folder to store keys and configuration files. The data stored in this folder will be decrypted when the folder is automatically mounted on logon.

Network equipment¶

Recommendations:

• Change initial vendor’s default passwords for all networking equipment to mitigate EoP.
• Use a network management utility provided by a vendor. The management utility helps to ensure that network operations are less error-prone and have adequate change management record history. Note, that a network equipment must be homogenic, provided by a single vendor.
• Document network equipment changes and use change management process such as ITIL / ISO 2000 service management techniques.

Networking service¶

Recommendations:

• Use an isolated management network to provide communication between the OpenStack Networking services and other OpenStack core services to mitigate spoofing and tampering attacks.
• Enable security groups to specify the type of traffic and a direction (ingress/egress) that is allowed to pass through a virtual interface port. Disable security groups in Compute service and proxy all security group calls to Networking API. To do that, set firewall_driver to nova.virt.firewall.NoopFirewallDriver to prevent nova-compute from performing iptables-based filtering; security_group_api to neutron to have all security group requests proxied to Networking service.
• Secure Networking API endpoint through TLS 1.2 or later. Use TLS 1.2 or later with available stack of ciphers. For example, you can use DHE-RSA-AES256-GCM-SHA384 cipher with DH public key size 3072 bit and private key size 256. In case of ECC, use TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 cipher with a 256 bits DH key length using elliptic curves. SP800-131A approves AES-128, 192, 256 bits encryption to mitigate information disclosure threat. See the Cryptography introduction section above.
• Keep private keys secure on API endpoints by using appropriate file permissions and other controls to mitigate information disclosure threat.
• Define a network policy enforcement (RBAC) to Networking-related actions, depending on customer’s requirements, policy, and use case to mitigate EoP threat. Customize the Networking policy.json file.
• Networking service separates projects by utilizing iptables along with ebtables rules. These rules prevents MAC and ARP spoofing attacks on virtual or NFV L2 layer.
• Configure per-tenant quotas for L2 and L3 resources and security groups for projects to avoid overconsumption of network resources and mitigate DoS attacks. See OpenStack Admin Guide for basic quotas configuration.

Authentication¶

General recommendations:

• Do not use simple login and password credentials, as Identity does not enforce policies on password strength, expiration, or failed authentication attempts as recommended by NIST Special Publication 800-118.
• Use Identity extensions or external authentication. To integrate Identity authentication with an existing directory service, use LDAP. You can map LDAP users into roles and groups within Identity in /etc/keystone/keystone.conf for use by the various OpenStack services.

External authentication

Use an SQL identity backend together with X.509 authentication or Kerberos for Keystone under Apache instead of using the username and password pair. Attributes coming with X.509 certificate could be matched against OpenStack identity data structures such as projects, domains, and groups.

Multi-factor authentication

Multi-factor authentication reduces the risk of passwords being compromised. We recommend using at least two-factor authentication (TFA) for privileged accounts such as admin to comply with NIST 800-53 IA-2(1) guidance.

Implement multi-factor authentication by leveraging the external authentication mechanism . Similar to the Federation scenario Keystone process is executed on Apache HTTPD. Once authenticated with multi-factor authentication mechanisms, Apache web server will pass down an authenticated user to Keystone using the REMOTE_USER environment variable.

Also we recommend that you enable TLS for client authentication to provide an additional factor of authentication. This requires certificates to be issued for OpenStack services, which can be self-signed and issued by internal authority. However, in this case you need to disable the validity check or mark a certificate as trusted.

Tokens

By default a token expiries in one hour. The recommended expiry value should be set to a lower value that allows enough time for internal services to complete tasks.

Fernet tokens are the most preferable to use. Fernet provides a secure messaging protocol specially designed for REST API communication being non-persistent and lightweight to reduce operational overhead. It uses AES-CBC to encrypt data and SHA HMAC to sign.

Domains

The Identity V3 API introduces a multi-tenancy model via using multiple domains where users can be represented with different authentication back ends and even have different attributes. Users of different domains can be mapped to a single set of roles and privileges, that are used in the policy definitions to access the various service resources.

You can enable domain-specific authentication drivers for multiple domains in the [identity] section of the keystone.conf file.

A domain owner can create additional users, groups, and roles to be used within the domain.

Groups

A group is a container representing a collection of users. Rather than assign a role directly to a user/project, a domain owner can assign a role to a group, and then add users to that group.

Brute-force prevention

The Identity service is susceptible to a brute-force attack. By default, the OpenStack Identity service does not provide the way to block accounts after repeated unsuccessful login attempts, which may lead to an OpenStack cluster compromise.

To counteract the brute-force attack:

• Specify the necessary strength of a user’s password.

• Detect the attack by reviewing of access control logs to discover unsuccessful attempts to access accounts.

  Note

  Currently, Keystone does not log information whether a particular login attempt was successful or not. There is no way to detect a brute-force attack with standard OpenStack services. To detect and count login failures, install WAF and check for the 401 Unauthorized HTTP response from the OpenStack Identity service.

• Prevent the attack by blocking a user’s IP after the specified number of unsuccessful login attempts by means of WAF. Find the use case below describing how to prevent the brute-force attack that attacker runs through the OpenStack Dashboard service on the Mirantis OpenStack controller.

  Note

  This approach does not work for authentication via the Keystone public API endpoint, because, as a side effect, WAF may block IP of proxy nodes in the HA cluster when a user reaches the limit of login failures made via the OpenStack Dashboard.Also, the brute-force prevention based on IP blocking is powerless when an attacker sends every new authentication request through a new proxy bot leveraging a botnet resources.

• Use multi-factor authentication for privileged user accounts.

Identity Federation¶

Identity Federation brings an ability to have several clouds served by the same Identity provider.

Requirements:

• Identity API v3 OS-FEDERATION Extension
• Apache 2.2.22 or later
• Ubuntu 12.04 or later

You can configure your Identity service to be used as a Service Provider or an Identity Provider.

There are three major protocols for Identity Federation: SAML, OpenID, and OAuth. Two of them are supported under Apache now:

• SAML 2.0 implementations:
  • Shibboleth
  • Mellon
• OpenID Connect

OpenStack Security Guide explains the way of configuring Federation using the Shibboleth protocol on Ubuntu with the Apache HTTPD server.

Authentication middleware¶

To secure the authentication middleware:

• Do not use a custom WSGI authentication middleware as it may bring additional security risks due to improper implementation.
• Remove admin_token middleware. This WSGI middleware effectively bypasses identification + authentication. There is no traceability or accountability in its use. It is exclusively intended for bootstrapping Identity service before any user accounts exists and is useful for a SQL-based identity deployment, but not necessarily against a read-only LDAP deployment.

To mitigate the risk admin_token middleware, disable it and move to domain-based approach for security management:

1. Create a new domain for cloud management purposes: cloud_admin_domain.

2. Assign the admin role to an appropriate user.

3. Update the Identity policy.json file to match newly created domain.

   Replace:

   "cloud_admin": [["rule:admin_required", "domain_id:admin_domain_id"]],
   

   with:

   "cloud_admin": [["rule:admin_required","domain_id:<cloud_admin_domain_id>"]],
   

4. Remove admin_token from /etc/keystone/keystone.conf.

5. Remove the admin_token auth middleware from /etc/keystone/keystone-paste.ini:

   [filter:admin_token_auth] paste.filter_factory = keystone.middleware:
   AdminTokenAuthMiddleware.factory
   

Block storage¶

To secure the block storage:

• Set strict access permissions (at least 640) for the following configuration files in /etc/cinder/: cinder.conf, api-paste.ini, policy.json, rootwrap.conf.

• Do not set the noauth value to parameter auth_strategy under the [DEFAULT] section.

• Enable TLS for authentication.

• Enable secure file permissions for Network-attached storage (NAS) by the following setting in /etc/cinder/cinder.conf:

  [DEFAULT]
  nas_secure_file_permissions = auto
  

• To avoid a DoS attack when an attacker sends an oversized request, verify osapi_max_request_body_size or max_request_body_size under the [oslo_middleware] section in /etc/cinder/cinder.conf is set to 114688:

  [DEFAULT]
  osapi_max_request_body_size = 114688
  
  [oslo_middleware]
  max_request_body_size = 114688
  

Object storage¶

To secure the object storage:

• Use a private (V)LAN network segment for your storage nodes in the data domain.
• Configure each Object Storage service to run under a non-root service account, for example use a username swift with the primary group swift.

Object storage architecture implies using whether an individual proxy node or multiple proxy nodes with a possibility to use a load balancer. Every proxy node should have at least two interfaces: public and private. Set up a firewall to protect the public interface on a proxy node. The public facing service on a the proxy node is an HTTP web server that handles endpoint client requests, authenticates them, and performs the appropriate action. The private interface establishes outgoing connections to storage nodes on the private storage network.

Ceph¶

To secure Ceph:

• Use cephx to authenticate users and daemons to protect against MitM attacks (information disclosure, tampering). The cephx tool uses shared secret keys for authentication.

  Note

  A network communication channel is not encrypted including the messages used to configure sared secret keys. The system is primarily intended to be used in trusted environments.

• For block storage encryption, Ceph-disk can utilize Linux dm-crypt functionality through the --dmcrypt parameter to mitigate information disclosure threat.

  Note

  The keys are stored in /etc/ceph/keys by default, which requires setting strict permissions for this folder.

• Use Ceph in a multi-project mode to mitigate EoP.

Enable CADF notifications in Keystone¶

To enable the CADF format notifications in the Identity service:

1. Set the notification_format option to cadf in the default section of keystone.conf:

   [DEFAULT]
   notification_format = cadf
   

2. Set a notification driver by specifying one of the possible values: messaging, messagingv2, routing, log, test, noop for the driver option in the oslo_messaging_notifications section:

   [oslo_messaging_notifications]
   driver = messagingv2
   

   Note

   You can also use the notification_driver parameter in the default section, which has been deprecated, to specify a destination for notifications.

   Note

   You can specify multiple notification drivers. For example, messagingv2 and log to send a notification to the RabbitMQ, as well as to print to a local Keystone log.

3. (Optional) Set an AMQP topic and custom transport URL.

   Note

   By default, notifications are sent to the notifications.info queue in RabbitMQ. You do not need to specify transport_url and topics in this case.

   For example:

   [oslo_messaging_notifications]
   transport_url = rabbit://{{ rabbitmq.user }}:{{ rabbitmq.password }}@{{ address('rabbitmq', rabbitmq.port) }}
   topics = keystone_notifications
   

4. (Optional) You can unsubscribe from specific type of notifications by using notification_opt   .. code-block:: ini_out option in the default section. For example, to opt-out noisy notifications with successful authentication, specify:

   [DEFAULT]
   notification_opt_out = identity.authenticate.success
   

5. Restart the Apache service for changes to take effect:

   service apache2 restart
   

6. Verify if the Identity service sends notifications in the CADF format.

   • See the Keystone log /var/log/keystone/keystone-public.log if the notification driver is set to log.

     For example:

     2017-01-26 09:19:01.307 27791 INFO
     oslo.messaging.notification.identity.authenticate
     [req-bf5a6c59-7f0f-4436-84c1-
     6dde1699f9cc - - - - -] {"event_type": "identity.authenticate",
     "timestamp": "2017-01-26 09:19:01.241364", "payload": {"typeURI":
     "http://schemas.dmtf.org/cloud/audit/1.0/event",
     "initiator": {"typeURI": "service/security/account/user",
     "host": {"agent": "keystoneauth1/2.3.0 python-requests/2.9.1
     CPython/2.7.6", "address": "192.168.0.2"}, "user_id":
     "42ca947ab83c4b86b843fccd36826a21",
     "id": "42ca947ab83c4b86b843fccd36826a21"}, "target":
     {"typeURI": "service/security/account/user", "id":
     "17b4cc7f-0ddb-51c7-8a55-aba8304f943c"}, "observer":
     {"typeURI": "service/security", "id":
     "e14fa14a-fb58-55e3-b38a-0cff3f9bd6f1"},
     "eventType": "activity", "eventTime": "2017-01-26T09:19:01.139486+0000",
     "action": "authenticate", "outcome": "failure", "id":
     "d286943b-ce61-5e98-80b4-24aa5c92980a"},
     "priority": "INFO", "publisher_id": "identity.node-6.domain.tld",
     "message_id": "4879d940-505d-4dbf-9005-bafafd150f0c"}
     

   • If the notification driver is set to messaging or messagingv2, see the RabbitMQ messages in the notifications.info queue set by default or in the queue with the name specified in the topic option. For example:

     {"oslo.message": "{\"priority\": \"INFO\", \"_unique_id\": \
     "950c821344064574bb401fb7bb58457f\", \"event_type\":
     \"identity.authenticate\", \"timestamp\": \"2017-01-25 15:29:37.003472\",
     \"publisher_id\": \"identity.node-6.domain.tld\", \"payload\":
     {\"typeURI\": \"http://schemas.dmtf.org/cloud/audit/1.0/event\",
     \"initiator\": {\"typeURI\": \"service/security/account/user\",
     \"host\": {\"agent\": \"keystoneauth1/2.3.0 python-requests/2.9.1
     CPython/2.7.6\", \"address\": \"192.168.0.2\"}, \"user_id\":
     \"42ca947ab83c4b86b843fccd36826a21\", \"id\":
     \"42ca947ab83c4b86b843fccd36826a21\"},
     \"target\": {\"typeURI\": \"service/security/account/user\",
     \"id\": \"d82204a0-d2a9-5034-affa-591d15a9391b\"}, \"observer\":
     {\"typeURI\": \"service/security\", \"id\":
     \"da9440a8-71ed-5a61-b747-9fc06164c2ee\"},
     \"eventType\": \"activity\", \"eventTime\":
     \"2017-01-25T15:29:36.316527+0000\",
     \"action\": \"authenticate\", \"outcome\": \"failure\", \"id\":
     \"c5cf0d09-d7e4-5526-bf22-fd20868ed7fd\"}, \"message_id\":
     \"3540d458-b03b-4c92-80bb-477e449112e5\"}", "oslo.version": "2.0"}
     

   • Use Ceilometer CLI to show the event of certain type:

     ceilometer event-list --query event_type=<EVENT_TYPE>
     

The example of the CADF Keystone notification formatted as a JSON document:

{
 "_unique_id": "950c821344064574bb401fb7bb58457f",
 "event_type": "identity.authenticate",
 "message_id": "3540d458-b03b-4c92-80bb-477e449112e5",
 "payload": {
 "action": "authenticate",
   "eventTime": "2017-01-25T15:29:36.316527+0000",
   "eventType": "activity",
   "id": "c5cf0d09-d7e4-5526-bf22-fd20868ed7fd",
   "initiator": {
   "host": {
   "address": "192.168.0.2",
   "agent": "keystoneauth1/2.3.0 python-requests/2.9.1 CPython/2.7.6"
   },
   "id": "42ca947ab83c4b86b843fccd36826a21",
   "typeURI": "service/security/account/user",
   "user_id": "42ca947ab83c4b86b843fccd36826a21"
   },
   "observer": {
   "id": "da9440a8-71ed-5a61-b747-9fc06164c2ee",
   "typeURI": "service/security"
   },
   "outcome": "failure",
   "target": {
   "id": "d82204a0-d2a9-5034-affa-591d15a9391b",
   "typeURI": "service/security/account/user"
   },
   "typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event"
 },
 "priority": "INFO",
 "publisher_id": "identity.node-6.domain.tld",
 "timestamp": "2017-01-25 15:29:37.003472"
}

Enable CADF notifications in other OpenStack services¶

To enable notification in the CADF format for other OpenStack services, define the audit filter in the api-paste.ini configuration file of an OpenStack service and include the audit filter into WSGI pipeline.

For example, to enable CADF notifications in the Compute service, follow the steps below:

1. Add the definition of the audit filter to /etc/nova/api-paste.ini:

   [filter:audit]
   paste.filter_factory = keystonemiddleware.audit:filter_factory
   audit_map_file = /etc/nova/api_audit_map.conf
   

2. Download api_audit_map.conf for Nova from the PyCADF repository:

   cd /etc/nova/
   wget https://raw.githubusercontent.com/openstack/pycadf/master/etc/pycadf/nova_api_audit_map.conf -O api_audit_map.conf
   

3. Add the audit filter into the Compute WSGI pipeline. For example:

   [composite:openstack_compute_api_v21]
   use = call:nova.api.auth:pipeline_factory_v21
   noauth2 = cors compute_req_id faultwrap sizelimit noauth2 osapi_compute_app_v21
   keystone = cors compute_req_id faultwrap sizelimit authtoken keystonecontext audit osapi_compute_app_v21
   

4. (Optional) Specify the service name and requests to be ignored by the filter:

   [filter:audit]
   service_name = test # opt to set HTTP_X_SERVICE_NAME environ variable
   ignore_req_list = GET,POST # opt to ignore specific requests
   

5. Add the notification condition into the default section of nova.conf:

   [DEFAULT]
   notify_on_state_change=vm_and_task_state
   

6. Set a notification driver in nova.conf by specifying one of the possible values: messaging, messagingv2, routing, log, test, noop for the driver option in the oslo_messaging_notifications section:

   [oslo_messaging_notifications]
   driver = messagingv2
   

   Note

   You can specify multiple notification drivers, for example, messagingv2 and log to send a notification to both: RabbitMQ and a local service log.

7. (Optional) Set an AMQP topic and custom transport URL. For example:

   Note

   By default, notifications are sent to the notifications.info queue in RabbitMQ. You do not need to specify transport_url and topics in this case.

   [oslo_messaging_notifications]
   transport_url = rabbit://{{ rabbitmq.user }}:{{ rabbitmq.password }}@{{ address('rabbitmq', rabbitmq.port) }}
   topics = nova_notifications
   

8. Restart the Compute WSGI server:

   service nova-api restart
   

9. Verify if the Compute service sends notifications in the CADF format.

   • If the notification driver is set to log, examine /var/log/nova/nova-api.log.

   • If the notification driver is set to messaging or messagingv2, see the RabbitMQ messages in the notifications.info queue set by default or in the queue with the name specified in the topic option.

   • Use Ceilometer CLI to show the event of certain type:

     ceilometer event-list --query event_type=<EVENT_TYPE>
     

Example of a JSON-formatted CADF notification:

{
 "_context_auth_token": "gAAAAABYifp1XvXY0S8yD8yav7hmqWRmFgy4gUwx1ryyEKxrrD7mIGpTOIItG71sOlhbUM9yzhDDSGe4ZBBQk554SU0qrhvINdAP1Jv6hEBwf1J27VWLIWLU5FVnBN1lv0vL26z2Vt3LKac_oYbvwpFByP_4lveza-cHk9fr2fnN0FPFvgPumiqqC0tyQG_ylYtdhSW5aepN",
  "_context_domain": null,
  "_context_instance_lock_checked": false,
  "_context_is_admin": true,
  "_context_project_domain": null,
  "_context_project_id": "298ace13a3bf4674a8af28286569f2d7",
  "_context_project_name": "admin",
  "_context_quota_class": null,
  "_context_read_deleted": "no",
  "_context_read_only": false,
  "_context_remote_address": "192.168.0.2",
  "_context_request_id": "req-f6b96abc-89ed-4a5c-afec-eacc05070568",
  "_context_resource_uuid": null,
  "_context_roles": [
    "admin"
  ],
  "_context_service_catalog": [
    {
     "endpoints": [
        {
        "adminURL": "http://192.168.0.2:8776/v2/298ace13a3bf4674a8af28286569f2d7",
        "internalURL": "http://192.168.0.2:8776/v2/298ace13a3bf4674a8af28286569f2d7",
        "publicURL": "https://public.fuel.local:8776/v2/298ace13a3bf4674a8af28286569f2d7",
        "region": "RegionOne"
        }
     ],
    "name": "cinderv2",
    "type": "volumev2"
    },
    {
    "endpoints": [
        {
        "adminURL": "http://192.168.0.2:8776/v1/298ace13a3bf4674a8af28286569f2d7",
        "internalURL": "http://192.168.0.2:8776/v1/298ace13a3bf4674a8af28286569f2d7",
        "publicURL": "https://public.fuel.local:8776/v1/298ace13a3bf4674a8af28286569f2d7",
        "region": "RegionOne"
        }
     ],
    "name": "cinder",
    "type": "volume"
    }
  ],
  "_context_show_deleted": false,
  "_context_tenant": "298ace13a3bf4674a8af28286569f2d7",
  "_context_timestamp": "2017-01-26T14:11:10.768205",
  "_context_user": "42ca947ab83c4b86b843fccd36826a21",
  "_context_user_domain": null,
  "_context_user_id": "42ca947ab83c4b86b843fccd36826a21",
  "_context_user_identity": "42ca947ab83c4b86b843fccd36826a21
  298ace13a3bf4674a8af28286569f2d7 - - -",
  "_context_user_name": "admin",
  "_unique_id": "8d688a79bf7b418380d2ad7b8f133b89",
  "event_type": "compute.instance.update",
  "message_id": "805ad852-1807-469b-a06e-b428b6916e87",
  "payload": {
    "access_ip_v4": null,
    "access_ip_v6": null,
    "architecture": null,
    "audit_period_beginning": "2017-01-01T00:00:00.000000",
    "audit_period_ending": "2017-01-26T14:11:11.078799",
    "availability_zone": "nova",
    "bandwidth": {},
    "cell_name": "",
    "created_at": "2017-01-26 13:26:53+00:00",
    "deleted_at": "",
    "disk_gb": 0,
    "display_name": "111",
    "ephemeral_gb": 0,
    "host": "node-7.domain.tld",
    "hostname": "111",
    "image_meta": {
    "base_image_ref": "22cf0b00-c01a-4158-b5f6-d5ee67f9db0f",
    "container_format": "bare",
    "disk_format": "qcow2",
    "min_disk": "0",
    "min_ram": "64"
    },
    "image_ref_url": "http://172.16.0.6:9292/images/22cf0b00-c01a-4158-b5f6-d5ee67f9db0f",
    "instance_flavor_id": "f786e6cf-3af9-4169-a95f-1478cfedcc8d",
    "instance_id": "40ab92ca-1c69-445e-b592-fe0b46d0ad9d",
    "instance_type": "m1.micro",
    "instance_type_id": 16,
    "kernel_id": "",
    "launched_at": "2017-01-26T13:30:40.000000",
    "memory_mb": 64,
    "metadata": {},
    "new_task_state": "deleting",
    "node": "node-7.domain.tld",
    "old_state": "active",
    "old_task_state": "deleting",
    "os_type": null,
    "progress": "",
    "ramdisk_id": "",
    "reservation_id": "r-f9fg0oxe",
    "root_gb": 0,
    "state": "active",
    "state_description": "deleting",
    "tenant_id": "298ace13a3bf4674a8af28286569f2d7",
    "terminated_at": "",
    "user_id": "42ca947ab83c4b86b843fccd36826a21",
    "vcpus": 1
  },
  "priority": "INFO",
  "publisher_id": "compute.node-6.domain.tld",
  "timestamp": "2017-01-26 14:11:11.106855"
}

Install ModSecurity on OpenStack controller¶

To install the latest version of ModSecurity on OpenStack controllers with Ubuntu 14.04, follow the steps:

1. Install required packages:

   sudo apt-get update && sudo apt-get upgrade
   sudo apt-get install --yes libyajl-dev libxml2 libxml2-dev
   liblua5.1 apache2-prefork-dev git
   

2. Enable unique_id for Apache that adds a magic token to each request to guarantee it is unique. The environment variable UNIQUE_ID is set to the identifier for each request.

   sudo a2enmod unique_id
   sudo service apache2 restart
   

3. Download ModSecurity and compile it with JSON support required for the OpenStack Identity service and other JSON-based APIs.

   cd ~
   wget https://www.modsecurity.org/tarball/2.9.1/modsecurity-2.9.1.tar.gz
   tar xvzf modsecurity-2.9.1.tar.gz
   cd modsecurity-2.9.1/
   ./configure --with-yajl="/usr/lib/x86_64-linux-gnu /usr/include/yajl"
   sudo make
   sudo make install
   

4. Create module configuration files

   sudo touch /etc/apache2/mods-available/security2.conf
   echo -e "<IfModule security2_module>\n\tSecDataDir
   /var/cache/modsecurity\n\tIncludeOptional /etc/modsecurity/
   .conf\n</IfModule>" >
   /etc/apache2/mods-available/security2.conf
   
   sudo touch /etc/apache2/mods-available/security2.load
   echo -e "LoadFile libxml2.so.2\nLoadModule security2_module
   /usr/lib/apache2/modules/mod_security2.so" >
   /etc/apache2/mods-available/security2.load
   
   mkdir -p /etc/modsecurity
   sudo cp modsecurity.conf-recommended unicode.mapping /etc/modsecurity/
   sudo mv /etc/modsecurity/modsecurity.conf{-recommended,}
   

5. Enable modsecurity module:

   sudo a2enmod security2
   sudo service apache2 restart
   

6. Turn on the ModSecurity engine with base rules for all sites on the given host.

   Note

   Verify that sites are not blocked by the rules due to the false positives. Test this before deploying to production.

   sudo sed -i 's/SecRuleEngine DetectionOnly/SecRuleEngine On/'
   /etc/modsecurity/modsecurity.conf
   

Create brute-force rules for ModSecurity¶

To create brute-force rules for ModSecurity WAF, follow the steps:

1. Create the configuration file in the /etc/modsecurity/ directory with .conf extension to detect the brute-force attack.

   Note

   ModSecurity enables all the /etc/modsecurity/* .conf files with rules after restarting Apache.

   The rules to block access from the specified IP for ten minutes after more than ten failed login attempts per controller:

   Note

   The limit for failed attempts is set per controller. Therefore, the overall limit is multiplied by the number of controllers. In this example, for three controllers the limit is 30.

   SecAction "phase:1,id:``10001``,pass,nolog,initcol:IP=%{REQUEST_HEADERS.x-forwarded-for}"
   
   # Check for horizon login ``/horizon/auth/login/``
   
   SecRule REQUEST_METHOD "@streq POST" "phase:5, chain,nolog,t:none,pass,id:``12341``"
   SecRule REQUEST_URI "(?i)(        )" "chain"
           SecRule RESPONSE_STATUS "^200" \
                   "setvar:IP.counter=+1"
   
   # Block for 10 minutes after 10 failed attempts per controller``
   
   SecRule IP:counter "@gt 10" \
         "phase:5,pass,t:none,id:'00012' \
         setvar:IP.block,\
         setvar:IP.counter=0,\
         expirevar:IP.block=600"
   
   #Reset counter after successful login (response is '302 FOUND')
   
   SecRule RESPONSE_STATUS "^302" \
   "phase:5,chain,t:none,nolog,pass,id:'00004',setvar:!IP.counter"
   SecRule REQUEST_URI "/horizon/auth/login/"
   
   
   # Block and log IP
   
         SecRule IP:block "@eq 1" \``
               "phase:2,deny,status:403,id:'00010',\``
               msg:'Brute-force attack detected - IP:
               %{REQUEST_HEADERS.x-forwarded-for}blocked for 10 min'"
   

   For debugging purposes, you may need to remove the block or reset the counter. To remove the block, uncomment the rules below and send the following request with the specified parameters from the blocked IP: GET /some_random_url/?=this_is_a_random_string:

   # Allow to disable the block / reset counter (uncomment following two rules to take effect)
   # In order to disable block send following request with parameters from blocked IP
   # GET /some_random_url/?=this_is_a_random_string
   
   # SecRule ARGS "@streq this_is_a_random_string" "id:``331331``,chain,log,msg:``Unblocking:
   %{REQUEST_HEADERS.x-forwarded-for}``, phase:1, setvar:!IP.block, setvar:!IP.counter"
   # SecRule REQUEST_URI "/some_random_url/"
   

2. Restart Apache to load the new rules:

   service apache2 restart
   

Verify alerts in log files¶

To verify that ModSecurity properly detects a brute-force attack through the OpenStack Dashboard, find the appropriate alert messages in the log files: /var/log/modsec_audit.log and /var/log/apache2/horizon_error.log.

For example:

Message: Access denied with code 403 (phase 2). Operator EQ matched 10 at IP:block.
[file "/etc/modsecurity/bruteforce.conf"] [line "38"] [id "00010"] [msg "Brute-force attack
detected - IP: 172.16.0.254 blocked for 10 min"]

Install IDPS¶

To install IDPS on a VM:

1. Configure network interfaces. For example:

   #The loopback network interface
   auto lo
   iface lo inet loopback
   
   #The internal network interface
   auto eth0
   iface eth0 inet dhcp
   
   #The external network interface
   auto eth1
   iface eth1 inet dhcp
   
   #The management network interface (recommended)
   auto eth2
   iface eth2 inet dhcp
   

2. Install Suricata IDPS.

   Note

   To enable NFQUEUE for IPS mode, install Netfilter packages and configure Suricata with --enable-nfqueue option before build. See the IPS mode with NFQUEUE section below for steps.

3. To capture traffic as it comes to a NIC avoiding packets reassembling by a network adapter, turn off offloads for a network interface you want to sniff. For example, configure eth0 with ethtool as root:

   ethtool -K eth0 rx off tx off sg off tso off gso off rxvlan off txvlan off gro off lro off
   

   Note

   If offloads are enabled, this may lead to reassembling incoming packets that results in changing packet structure and increasing its size. Suricata may not process reassembled packets correctly. If GRO and LRO are enabled, you will see the error message when launching Suricata:

   [ERRCODE: SC_ERR_PCAP_CREATE(21)] - Using Pcap capture with GRO or LRO
   activated can lead to capture problems.
   

4. To extract files over 1 Mb in size from HTTP traffic, increase a value of the stream engine option stream.reassembly.depth (default is 1 Mb), which controls the depth into a stream in which Suricata looks, or set to 0 for no limit in suricata.yaml.

You can run IDPS in two modes based on a service type:

• IDS (Contrail’s Analyzer)

  Analyzing traffic and generating alerts.

• IPS or inline (Contrail’s Firewall)

  Blocking or modifying packets and generating alerts.

You can deploy IDPS in two ways based on a service mode:

• As a router (Contrail’s In-Network)

  IDS or IPS is placed between at least two networks and packets are routed.

• As a bridge (Contrail’s Transparent)

  IDS or IPS forwards packets between network interfaces without modification.

IDS mode¶

In IDS mode you can use the following actions:

• Pass

  Stops scanning the packet matched by a signature and skips to the end of allrules (only for this packet)

• Alert

  IDS fires up an alert for the packet matched by a signature

To set up IDS as a router between two networks, configure iptables to forward and masquerade packets between networks.

To route traffic in IDS mode between internal network connected to the eth0 network interface of the IPS VM and external network connected to eth1, run the following commands:

sysctl -w net.ipv4.ip_forward=1
/etc/init.d/networking restart
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

To test the IDS mode on the created VM:

1. Create /etc/suricata/rules/test.rules file and write the following rule:

   alert http any any -> any any (msg:"Alarm detected"; content:"Alarm"; nocase;
   classtype:policy-violation; sid:1; rev:1;)
   

2. Add test.rules to a list of rules in the suricata.yaml configuration file.

3. Reboot IDPS VM or start Suricata manually in a daemon mode:

   sudo suricata -c /etc/suricata/suricata.yaml -i eth0 -D
   

4. Verify if suricata.log contains no errors after Suricata starts up:

   tail -f /etc/suricata/suricata.log
   

5. Make any HTTP request with the word Alarm. For example:

   curl http://google.com/Alarm
   

6. View the fast.log to check if Suricata generated the appropriate alert message: Alarm detected:

   tail -f /etc/suricata/fast.log
   

IPS mode¶

In IPS mode you can block traffic bridged between two network interfaces using the following actions:

• Drop

  A packet containing a signature is discarded immediately and will not be sent any further. The receiver does not receive a message resulting in a time-out. All subsequent packets of a flow are dropped.

• Reject

  An active rejection of the packet, both a receiver and sender receive a reject packet. If the packet concerns TCP, it will be a reset-packet, otherwise it will be an ICMP-error packet for all other protocols.

To enable IPS or inline mode (the Firewall Contrail’s service type),​ use:

• NFQ

  Netfilter on Linux.

  Note

  NFQ supports multiple queues processing, which you should specify explicitly in iptables rules and suricata command line options. For example, you can configure load balancing with NFQ as follows:

  iptables -A INPUT -j NFQUEUE --queue-balance 0:3
  suricata -c /etc/suricata/suricata.yaml -q 0 -q 1 -q 2 -q 3
  

• IPFW

  A divert socket on FreeBSD.

• AF_PACKET

  Level 2 Linux bridge, which supports automatic load balancing for better performance.

• PF_RING

  Improve your performance with PF_RING ZC if your NIC supports Zero Copy (ZC) mode as well.

Enable file extraction¶

The file extraction feature has been included in Suricata since the version 2.0. The feature enables file extraction from HTTP and SMTP traffic. You can take advantage of this feature when you want to analyze incoming files from Web or mail traffic in a sandbox or multiscanner.

To enable file extraction feature, follow the steps below:

1. In the test.rule file, create or modify a rule to add the filestore option:

   alert http any any -> any any (msg:"Alarm detected"; content:"Alarm"; nocase;
   classtype:policy-violation; filestore ; sid:1; rev:1;)
   

2. Verify that you have a proper value for the stream engine option stream.reassembly.depth (default 1 Mb) in suricata.yaml. Increase the value for files greater than 1Mb or set to 0 for no limit.

3. Verify that you turned off the offloads rx, tx, sg, tso, gso, rxvlan, txvlan, gro, lro:

   ethtool -k eth0
   

4. Start Suricata or reload the active ruleset:

   kill -USR2 <suricata pid>
   

5. Download the test text file containing the word Alarm inside on the IDPS VM:

   wget http://<web server IP>:8080/test
   

6. Go to the folder with extracted files:

   cd /var/log/suricata/files
   

7. View the file.1 content if it equals to the downloaded test file:

   sudo cat file.1
   

   Example of system output:

   Alarm
   

8. Open file.1.meta to see the file’s metadata:

   sudo cat file.1.meta
   

   Example of system output:

   TIME: 05/12/2016-18:02:58.514611
   SRC IP: 10.20.0.2
   DST IP: 10.20.0.8
   PROTO: 6
   SRC PORT: 8080
   DST PORT: 41632
   APP PROTO: http
   HTTP URI: /test
   HTTP HOST: 10.20.0.2
   HTTP REFERER: <unknown>
   HTTP USER AGENT: Wget/1.15 (linux-gnu)
   FILENAME: /test
   MAGIC: ASCII text
   STATE: CLOSED
   MD5: cb545549b596e5235285364023d07146
   SIZE: 6
   

9. More rules to detect and extract Windows and Linux executables are below:

   alert http any any -> any any (msg:"==ELF file=="; content:"ELF"; distance:0;
   classtype:policy-violation; filestore;sid:3; rev:1;)
   
   alert http any any -> any any (msg:"==PE file=="; content:"|0D 0A 0D 0A|MZ";
   distance:0; classtype:policy-violation; filestore;sid:4; rev:1;)
   
   alert http any any -> any any (msg:"==EXE file=="; fileext:"exe";
   classtype:policy-violation; filestore;sid:14; rev:1;)
   

Run in daemon mode¶

When you deploy Suricata on a service instance, you can start Suricata automatically on system boot up and run in a daemon mode.

To run Suricata in the daemon mode:

1. Disable console output and set it to a file in the suricata.yaml configuration file:

   outputs:
   - console:
        enabled: no
   - file:
        enabled: yes
        filename: /var/log/suricata.log
   

2. Make Suricata start on system boot up:

   • Create the initialization script /etc/init/suricata.conf:

     # suricata
     description "IDPS Daemon"
     start on runlevel [2345]
     stop on runlevel [!2345]
     expect fork
     exec suricata -D --pidfile /var/run/suricata.pid -c
     /etc/suricata/suricata.yaml -i eth0
     

   or

   • Specify the --pidfile option in suricata.yaml.

Alerts management¶

Configure your SIEM solution to process, store, and visualize the alerts generated by IDPS.

Alternatively, you can use Barnyard2 and Snorby open source solutions.

IDPS as a VNF¶

In OpenStack environments with a network functions virtualization infrastructure (NFVI) enabled you can run an IDPS instance as a virtualized network function (VNF). VNFs are building blocks that you can use to create a scalable service that includes a sequence of virtual functions in service chaining.

To enable IDPS as a VNF:

1. Once IDPS VM is configured and verified, upload the IDPS VM image to your cloud environment using OpenStack Dashboard. QCOW2 or VMDK formats of the image are preferable.

2. Go to the Contrail web UI. For example: https://172.16.0.3:8143/

3. Open the Service Templates panel in the Configure tab.

4. Create an IPS template service.

   1. Select the service mode for your service:

      • In-Network or routed mode

        Service VM instance is between at least two networks and packets are routed. Examples include NAT, Layer 3 firewall, load balancer, HTTP proxy, and so on.

      • In-Network NAT

        Similar to in-network mode. However, return traffic does not need to be routed to the source network. In-network-nat mode is particularly useful for NAT service.

      • Transparent or bridge mode

        Is transparent for communication between instances and packets are not modified. The transparent mode fits L2 firewall and IDPS.

   2. Specify the number of interfaces for a service in Service Type.

      • For Firewall type Contrail allocates at least two interfaces: ingress and egress.
      • For Analyzer type - at least one interface is needed.
      

   3. In Advanced Options you can enable Service Scaling, select Availability Zone for your service instances, and select an instance flavor.

      

5. In Service instances panel, create an ips-instance service instance based on the available service template and connect network interfaces to internal and external networks. As a result, ips-instance will act as an alternative router connecting two networks.

   

6. Go to the Networking->Policies panel to create a service policy. The ips-policy tells Contrail to pass any traffic between internal and external to the ips-instance service instance.

   

   Note

   OpenContrail provides traffic mirroring feature as well.

7. Assign the created ips-policy policy to the affected networks internal and external in the Networking->Networks panel.

8. Test your service chaining:

   1. Create a VM TestVM from where you can download malicious content from external network.

   2. Configure iptables to route traffic between internal and external traffic (a router mode).

      Note

      You can also test your IPS service instance in a bridge mode by installing it between the default router and external network.

   3. The current network topology with ips-instance and the TestVM running in the internal network will look like:

      

   4. Verify if Contrail correctly direct traffic between networks to the service instance.

      1. From the TestVM ping the external network gateway. For example:

         ping 172.16.0.1
         

      2. On the ips-instance VM, start tcpdump:

         sudo tcpdump -i eth0
         

      3. In the ips-instance VM, verify that you can see ICMP packets going between two networks:

   5. Set up a web server in external network and create a test file with the word Alarm inside.

   6. Download the test file from TestVM. For example:

      curl http://172.16.0.30:8080/test
      

   7. In the ips-instance VM, view the fast.log to check if Suricata generated the appropriate alert message: Alarm detected:

      tail -f /etc/suricata/fast.log
      

STIG hardening recommendations¶

The Security Technical Implementation Guides (STIGs) are the configuration standards for secure installation and maintenance of computer software and hardware introduced by Defense Information Systems Agency (DISA) in support of the United States Department of Defense (DoD). The guides include recommended administrative processes to reduce exploitation possibility. STIG scanning software is used to implement and validate proper configuration.

Verify that your Linux host comply with the STIG recommendations. For example:

1. The system must not permit interactive boot. To disable the ability forusers toperform interactive startups, edit the file /etc/sysconfig/init. Add or correct the line:

   PROMPT=no
   

   The PROMPT option allows the console user to perform an interactive system startup, in which it is possible to select the set of services which are started on boot.

2. All rsyslog-generated log files must be owned by root and have mode 0600 or less permissive. The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access. The owner of all log files written by rsyslog should be root.

3. The system must set a maximum audit log file size. The total storage foraudit log files must be large enough to retain log informationover the period required. This is a function of the maximum logfile size and the number of logs retained. Determine the amount of audit data (in megabytes - at least 6 Mb) that should be retained ineach log file. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting the correct value for [STOREMB]:

   max_log_file = [STOREMB]
   

4. The audit system must be configured to audit successful file system mounts. The unauthorized exportation of data to external media could result in an informationleak where classified information, Privacy Act information, and intellectual property could be lost. An audit trail should be created each time afilesystem is mounted to help identify and guard against informationloss. At a minimum, the audit system should collect media exportationevents for all users and root. Add the following to /etc/audit/audit.rules, setting ARCH to either b32 or b64 as appropriate for your system:

   -a always,exit -F arch=ARCH -S mount -F auid>=500 -F auid!=4294967295 -k export
   -a always,exit -F arch=ARCH -S mount -F auid=0 -k export
   

5. The SSH daemon must set a timeout interval on idle sessions. Causing idle users to be automatically logged out guards against compromises one system leading trivially to compromises on another. SSH allows administrators to set an idle timeout interval. After this interval has passed, theidle user will be automatically logged out. To set an idle timeout interval, edit the following line in /etc/ssh/sshd_config as follows:

   ClientAliveInterval <INTERVAL>
   

   The timeout interval is given in seconds. To have a timeout of 15 minutes, set the interval to 900. If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made here. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle.

6. The SSH daemon must not permit user environment settings. SSH environment options potentially allow users to bypass access restriction in some configurations. To ensure users are not able to present environment options to the SSH daemon, add or correct the following line in /etc/ssh/sshd_config:

   PermitUserEnvironment no
   

7. The SNMP service must not use a default password. Presence of the default SNMP password enables querying of different system aspects and could result in unauthorized knowledge of the system. Edit /etc/snmp/snmpd.conf, remove default community string public. Upon doing that, restart the SNMP service.

8. The system default umask for the bash shell and in /etc/profile must be 077. The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read and/or written to by unauthorized users.

   • To ensure the default umask for users of the Bash shell is set properly, add or correct the umask setting in /etc/bashrc to read as follows:

     umask 077
     

   • To ensure the default umask controlled by /etc/profile is set properly, add or correct the umask setting in /etc/profile to read as follows:

     umask 077
     

9. Auditing must be enabled at boot by setting a kernel parameter. Each process on the system carries an auditable flag which indicates whether its activities can be audited. Although auditd takes care of enabling this for all processes which launch after it does, adding the kernel argument ensures it is set for every process during boot. To ensure all processes can be audited, even those which start prior to the audit daemon, add the argument audit=1 to the kernel line in /etc/grub.conf as follows:

   kernel/vmlinuz-version ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet audit=1.
   

10. The Bluetooth kernel module must be disabled preventing the kernel from loading thekernel module provides an additional safeguard against its activation. The kernel’s module loading system can be configured to prevent loading of the Bluetooth module. Add the following to the appropriate /etc/modprobe.d configuration file to prevent the loading of the Bluetooth module:

    install net-pf-31 /bin/false install bluetooth /bin/false
    

Use the openstack-ansible-security role to provide host security hardening for OpenStack environments deployed with Openstack-Ansible.

FedRAMP recommendations¶

The FedRAMP program provides documents and templates with details needed to comply with FedRAMP requirements.

PCI DSS recommendations¶

Find the quick summary of PCI DSS recommendations below:

1. Restrict the use of administrative functions to defined endpoint networks and devices, such as specific laptops or desktops that have been approved for such access.
2. Require multi-factor authentication for all administrative functions.
3. Ensure that all changes are implemented and tested properly. Consider requiring additional management oversight, above and beyond that which is required through the normal change-management process.
4. Separate administrative functions such that hypervisor administrators do not have the ability to modify, delete, or disable hypervisor audit logs.
5. Send hypervisor logs to physically separate, secured storage as close to real-time as possible.
6. Monitor audit logs to identify activities that could indicate a breach in the integrity of segmentation, security controls, or communication channels between workloads. Implement an automatic log analysis solution and develop scripts notifying of all potentially harmful actions, according to company security policy.
7. Separate duties for administrative functions, such that authentication credentials for the hypervisor do not have access to applications, data, or individual virtual components.

Investigate and prevent targeted attack (APT)¶

Typically, Advanced Persistent Threats (APTs), as well as backdoors, communicate with C&C servers to get commands from attackers and send back collected information. The network traffic is usually encrypted and sent via a usual http port. This prevents it from being detected by Network Data Leakage Prevention (DLP) or antivirus systems. However, every APT generates a specific traffic that contains unique network IoCs. Based on the analysis of network behavior of recent APTs, it is possible to reveal patterns of targeted attacks to detect still unknown cyber espionage campaign.

For example, the CozyDuke (Office Monkeys) APT sends http requests to the hacked website acting as a proxy C&C server, which replies with the specific for the victim set of payload modules. The transmitted data is Base64 encoded. After taking Base64 off, the HTTP stream contains a binary content that seems to be an encrypted executable.

To analyse further, disassemble the backdoor to find out the algorithm (RC4) used for traffic encryption.

Analysing the code, it is possible to find the RC4 key in the memory when the backdoor exports it in a BLOB format to be stored as a header before the encrypted data. The key is 16 bytes and generated every time a new session is created:

The network packet before being encoded with Base64 contains the key at the beginning, so the server can use it to decrypt the message:

The same key is used to encrypt local configuration file of the backdoor called racss.dat.

The XML config file shows the C&C proxy server addresses. According to the information in <Servers> section, two URLs are used to establish the connection with the C&C proxy, which is merely a someone’s hacked website.

After the short analysis of the threat, network IoCs were found. You can add these network IoCs to the rules of NGFW/IDPS solutions deployed in your cloud. Once blacklists are updated you can monitor if there are more infected machines in a subnet or within a whole cluster.

For incident response, it is important to reveal a security breach and fix it to prevent the penetration in future. In case of the analyzed attack, no exploits were used, but spear-phishing and social engineering methods. In this case, you need to scan SMTP traffic and create rules to block suspicious attached files according to the corporate security policy.

To prevent targeted attacks (APTs):

• Terminate TLS on (reverse-)proxy servers for both incomig and outgoing traffic.

• Filter out executable and documents from incoming traffic.

• Scan the extracted from traffic incoming files with an antivirus solution.

• Open the extracted executable and documents from incoming traffic in a sandbox to verify their behaviour for being malicious.

• Mirror documents excluding active content such as embedded scripts.

• Enable TOR blocking rules on network IDPS.

  Note

  APTs can communicate with a C&C server in the TOR network. The outgoing TOR traffic can be encapsulted into HTTP and encrypted with TLS to be delivered through a public CDN network to TOR using the domain fronting technique.

Example of threat modeling for Ceph RBD¶

The example presents a threat modeling process for Ceph RBD. You can use the Microsoft Threat Modeling Tool to draw a data flow diagram (DFD) and run threat modeling using the STRIDE threat model described in this document.

After modeling is completed, the tool suggests a list of potential threats to be mitigated. The tool distributes the discovered threats between interactions. Therefore, the report suggests the list of threats by categories connected to a particular interaction (data flow) on the diagram. Below you can find modeling information by the Microsoft Threat Modeling Tool for each interaction.

An example of threat modeling for the Monitor Data Flow interaction:

1. Spoofing of Destination Data Store Generic Data Store [State: Not Started] [Priority: High]

   Category:	Spoofing
   Description:	Ceph Monitor (controller) may be spoofed by an attacker and this may lead to data being written to the attacker’s target instead of Ceph Monitor (controller). Consider using a standard authentication mechanism to identify the destination data store.
   Justification:	<no mitigation provided>

2. Data Store Inaccessible [State: Not Started] [Priority: High]

   Category:	Denial Of Service
   Description:	An external agent prevents access to a data store on the other side of the trust boundary.
   Justification:	<no mitigation provided>

3. Data Flow Generic Data Flow Is Potentially Interrupted [State: Not Started] [Priority: High]

   Category:	Denial Of Service
   Description:	An external agent interrupts data flowing across a trust boundary in either direction.
   Justification:	<no mitigation provided>

4. Potential Excessive Resource Consumption for OS Process or Generic Data Store [State: Not Started] [Priority: High]

   Category:	Denial Of Service
   Description:	Does Qemu Process or Ceph Monitor (controller) take explicit steps to control resource consumption? Resource consumption attacks can be hard to deal with, and there are times that it makes sense to let the OS do the job. Be careful that your resource requests don’t deadlock, and that they do timeout.
   Justification:	<no mitigation provided>

5. Data Flow Sniffing [State: Not Started] [Priority: High]

   Category:	Information Disclosure
   Description:	Data flowing across Monitor Data Flow may be sniffed by an attacker. Depending on what type of data an attacker can read, it may be used to attack other parts of the system or simply be a disclosure of information leading to compliance violations. Consider encrypting the data flow.
   Justification:	<no mitigation provided>

6. Data Store Denies Generic Data Store Potentially Writing Data [State: Not Started] [Priority: High]

   Category:	Repudiation
   Description:https://www.microsoft.com/en-us/sdl/adopt/threatmodeling.aspx	Ceph Monitor (controller) claims that it did not write data received from an entity on the other side of the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
   Justification:	<no mitigation provided>

7. The Generic Data Store Data Store Could Be Corrupted [State: Not Started] [Priority: High]

   Category:	Tampering
   Description:	Data flowing across Monitor Data Flow may be tampered with by an attacker. This may lead to corruption of Ceph Monitor (controller). Ensure the integrity of the data flow to the data store.
   Justification:	<no mitigation provided>

8. Authenticated Data Flow Compromised [State: Not Started] [Priority: High]

   Category:	Tampering
   Description:	An attacker can read or modify data transmitted over an authenticated dataflow.
   Justification:	<no mitigation provided>