Skip navigation
Share This:


What is POODLE Vulnerability

On October 14, 2014, a security vulnerability affecting Secure Socket Layer version 3 (SSL v3.0) was publicly disclosed (Padding Oracle On Downgraded Legacy Encryption, or “Poodle”). This security vulnerability is the result of a design flaw in SSL v3.0. Note that this vulnerability does not affect TLS and is limited to SSL 3.0, which is widely considered as an obsolete protocol. This vulnerability has received the identifier CVE-2014-3566.

This vulnerability involves man-in-the-middle (MITM) network access in conjunction with a certain amount of control over the user's browser to have it make repeated requests with content under the attacker's control and also heavy real-time computing power.


To resolve this issue, the SSL 3.0 protocol is disabled in all the HTTPS connections within BMC Network Automation (BNA). BNA allows HTTPS connection for the following -


1. BNA server communication

BMC Network Automation uses the Apache Tomcat web server. Therefore, the server.xml file was modified to use a new attribute, sslEnabledProtocols. By default, this attribute is set to TLSv1, TLSv1.1, TLSv1.2

 

2. Communication between BNA agent and network device

BMC Network Automation allows HTTPS communication with some devices. A new property, httpsEncryptionProtocols that contains “TLSv1,TLSv1.1,TLSv1.2” as the default value has been added to the global.properties.imported file.

 

3. Communication between BNA Server and BNA Agent

The BMC Network Automation server communicates with BMC Network Automation agent over HTTPS protocol. This communication uses the TLSv1.2 as the default SSL protocol for communication. This protocol is configurable via agentSSLProtocol property in the global.properties.installed file.

 

Following versions of BMC Network Automation are POODLE safe

BNA 8.5.01 HF#15

BNA 8.6.00 HF#2

BNA 8.6.00.001 onwards

Share This:


What is the DNS feature offered by BMC Network Automation?

BMC Network Automation (BNA) introduced a feature in the 8.6.00.001 release to be able to register DNS addresses of VMs provisioned within Cloud Lifecycle Management(CLM) on-premise containers and CLM public containers (AWS, Azure).  BNA allows setting of DNS properties such as Primary DNS Server, Secondary DNS Server, Primary Domain Suffix for NIC, Reverse DNS Zone and Domain Search Order for each address pool (network). This means that user can use different DNS servers per network. When the VM is provisioned the NIC address will be registered into DNS server. When the VM is decommissioned the DNS record associated with the VM is also deleted from the DNS server. BNA facilitates the DNS registration and deregistration for VM provisioning and decommissioning. The supported DNS servers include Windows DNS server, Linux DNS server and Infoblox DNS server. BNA delegates DNS registration and deregistration operation to a BMC Atrium Orchestrator (BAO) workflows so BAO needs to be configured accordingly. Note that this feature is available with CLM 4.5 release which is Byington.


How to use the DNS feature offered by BMC Network Automation

The fundamental requirements for using the out of the box DNS feature in BMC Network automation are as follows:

1.    The BNA global property – performDnsOperation set to true. Default value is false.

2.    Set the DNS properties. BNA allows to set the different DNS properties per addressPool in the BNA Pod or Container. If you want to set the DNS properties for a Pod Address Pool, you can view the Pod in BNA UI and start editing the DNS properties.

 

https://docs.bmc.com/docs/display/public/bna86/Editing+a+pod#Editingapod-dns_info_edit


If you have the container already created and you want the container address pool to use the DNS, you can set the DNS properties for the container address pool by using the container_utils CLI utility offered by BNA.

https://docs.bmc.com/docs/display/public/bna86/Using+the+container+utilities+script#Usingthecontainerutilitiesscript-address_pool_override


Note - This step is necessary only for the CLM on-premise containers. For the CLM public containers (AWS, Azure), the DNS properties are required to be set in the CLM UI while provisioning the container.


3.    Once you have the DNS properties defined you need to tell CLM that whenever the VM is provisioned from a specific address pool, you want it to be DNS registered. For this, the service blueprint needs to be updated in CLM to select the flag called DNS Registration Required for the NIC of the VM.


Note – This check box enables you to select the private IP Or public IP options. The CLM on-premise containers allows the DNS registration only for the private IP.  However for the CLM public (AWS, Azure) containers you can select Private IP or Public IP options under this flag.


Following is the BMC documentation link which will be helpful to understand more about this feature.

https://docs.bmc.com/docs/display/public/bna86/Defining+a+DNS+server+in+BMC+Network+Automation


Setting up BAO for DNS feature

https://docs.bmc.com/docs/display/public/clm41/Configuring+BMC+Atrium+Orchestrator+for+automatic+DNS+registration

 

 

-Pooja

 

 

 

Filter Blog

By date:
By tag: