Release Automation

Expand all | Collapse all

Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

Jump to Best Answer
  • 1.  Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Posted 06-30-2016 01:22 AM

    Hi everyone,

     

    we have the following scenario, where we want to deploy something into a DMZ, to achieve that we installed an execution server and an agent in the DMZ and connected the execution server to the one outside the DMZ that is connected to our management server

     

    so basically:

    - non-DMZ: Management Server -> Execution Server

    - DMZ: Execution Server -> Agent

     

    we successfully connected both execution servers so that we're able to deploy into the DMZ but now we of course need to secure the communication, at least on the transition from non-DMZ to DMZ.

     

    When checking the Wiki, I can only find these scenarios (Secure Communications - CA Release Automation - 6.1 - CA Technologies Documentation  ):

    - Secure UI Communication

    - Management to Execution Server

    - Execution Server to Agent

     

    Currently I'm assuming I would need to follow the steps of securing the communication between execution server and agent to also secure it for execution server to execution server. Can anyone confirm this?

     

    Also when we follow these steps, do we also need to install certificates on the agents or do both ways to communicate work at the same time? (I would believe they do, but I'm just not sure, because it is not a topic I'm very familiar with)

     

    Thanks.

    Michael



  • 2.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)
    Best Answer

    Broadcom Employee
    Posted 06-30-2016 04:18 AM

    Hi,

     

         To encypt the nimi connection you need to edit the nimi_config.xml on the execution server and set this value to true

     

         <security>

              <enabled>true</enabled>

     

         This will use the certificates that are shipped with the product. You do not need to follow the steps to use your own certificates unless you actually want to use your own custom certificates.

     

    Hope this helps

    Keith



  • 3.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Posted 06-30-2016 04:23 AM

    Hi Keith,

     

    the thing is, I have no idea if we need or own certificates.

     

    what I know is, that we needed our own for securing the UI communication as we got errors on the UI that the certificate is not valid and we we're not allowed to put the CA certificates in the truststore.

     

    so, if we now would use the CA certificates for the execution to executions server communication would those work?

     

    thanks

    michael



  • 4.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Posted 06-30-2016 08:41 AM

    I believe NES to NES communication will work using RA default certificates



  • 5.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Posted 07-01-2016 02:12 AM

    Hi Jacky,

     

    alright, we'll try it.

     

    thanks

    michael



  • 6.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Broadcom Employee
    Posted 07-07-2016 05:58 PM

    nelje05 wrote a very thorough, in-depth knowledge base document (titled "SSL Configuration, Release Automation 5.0+") on this topic that covers several different scenarios. It might be of interest to you, and can be found here: http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec1654745.aspx?intcmp=searchresul…



  • 7.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Posted 07-14-2016 03:01 PM

    Hi MichaelGebhardt,

     

    Did any of these responses help to answer your question? Please remember to mark the most helpful response as correct!

     

    Thanks!

    Melanie



  • 8.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Posted 07-15-2016 01:05 AM

    Hi Melanie,

     

    we prepared everything for a VAPT that still needs to be done by colleagues of us in toronto, but the one responsible is on holidays at the moment.

     

    if you want, I can mark the question as assumed answered for now, but I might reopen it, if the VAPT shows, that the flag alone isn't enough.

     

    thanks

    michael



  • 9.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Posted 07-15-2016 09:41 AM

    Hi Michael,

     

    That's fine if you want to leave the question open until confirmed! Just wanted to make sure you hadn't forgotten about it. Thanks for the update!

     

    Thanks!

    Melanie



  • 10.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Posted 08-23-2016 12:14 PM

    Hi Michael - any updates here? Would be great if you could post whatever worked for any other users who may have the same question.



  • 11.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Posted 08-24-2016 01:09 AM

    hi melanie, sadly no updates, appears that the one doing the vapt will be back in september.



  • 12.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Posted 09-20-2016 02:03 AM

    To follow up on this, the VAPT was finally done and the communication on port 6600 was deemed secure, they only found the hashing algorithm on port 22450 (connection to database) and the hashed user id and password. so they said once the password hash is extracted, it can possibly quite quickly be brute forced.

     

    but, that's another topic.

     

    thanks Keith-Puzey-CA



  • 13.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Posted 11-23-2016 08:44 AM

    Hey Keith-Puzey-CA,

     

    sorry to pull this up again, but this is going on for quite some time now internally for us.

     

    now they also want us to inform you guys about the issue, that the traffic on port 22450 indicated sensitive data as it is showing the MD5 hashed user password.

     

    So, I'm now just wondering who I can contact about that issue offically. Should I simply open a case for that? It is more, that our security guys see, that we approached you and informed you about that, so that you might solve it in the future...

     

    thanks,

    Michael

     

    (JamesPanetti also tagging you here, as you might give an answer to that as well)



  • 14.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Broadcom Employee
    Posted 11-24-2016 09:29 AM

    Hi Michael,

     

             Could you please raise an issue for this and we will raise your concern with the engineering team.

     

    Regards

    Keith



  • 15.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Posted 11-25-2016 02:37 AM

    Hi Keith,

     

     

    I created case 00613851

     

    Best regards

    Michael



  • 16.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Broadcom Employee
    Posted 11-25-2016 03:05 AM

    Thanks Michael,

     

            i will talk to engineering, can i check one thing. in the issue you say the DB port is being opened from the execution server to the database is this correct? All connectivity with the DB is via the NAC if you are seeing a DB connection from the execution server what other components are installed on the execution server?

     

    Regards

    Keith



  • 17.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Posted 11-25-2016 07:09 AM

    we thought it might be the execution server, as we probably didn't know, which server does what when it comes to internal communications within CA-RA

     

    the only thing mentioned in the report was traffic on the 22450 port, which is our database port to the CA-RA ms sql db, and in there a MD5 hashed password was found, what was deemed insecure.

     

    we don't use any db actions or what so ever for the test deployment, so it must be the general communication to the DB during a deployment run, where internal infos are being read and also wrote to the CA-RA db.

     

    best regards

    michael



  • 18.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Broadcom Employee
    Posted 11-25-2016 08:01 AM

    Hi,

         All the communication from the NES to the DB is over ActiveMQ / Http via the NAC, The NES should not be making any connection to the Database. Is it possible to look at NetStat on the NES and confirm which process is initiating the DB connection?

     

    Regards

    Keith



  • 19.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Posted 11-28-2016 03:19 AM

    Hi Keith,

     

    I honestly have no idea what you're talking about. What is NetStat? a tool? CA-RA logs?

     

    we didn't run the VAPT, we just received an analysis report, that pointed this out. I did send this report to DirkBleyenberg has he is or was working on the case.

     

    We do have stefan in the house this week, because of a PoC for the CDE, if there is time, I'll talk about it with him.

     

    best regards

    Michael



  • 20.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Broadcom Employee
    Posted 12-07-2016 08:21 AM

    Hi Michael,

     

        I have been out of the office for the past week, were you able to resolve the problem?

     

    Regards

    Keith



  • 21.  Re: Secure Communication: Execution Server (non-DMZ) to Execution Server (DMZ)

    Posted 12-08-2016 02:51 AM

    Hi Keith,

     

    yes, the one who did the test had a typo, which caused the confusion. in the end the communication on this port was between management and database server, which is then the normal JDBC connection. Dirk pointed into a direction how we could secure it, if necessary. We might not need to do it, as both servers are in the same intranet, before it was trouble as one was in the intranet and the other in the dmz.

     

    Thanks,

    Michael