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

[Michael Gebhardt]

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

[Keith Puzey]

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

[Michael Gebhardt]

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

[Jacky_Mahadab]

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

[Michael Gebhardt]

Hi Jacky,

 

alright, we'll try it.

 

thanks

michael

[James Panetti]

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…

[Melanie_Giuliani]

Hi MichaelGebhardt,

 

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

 

Thanks!

Melanie

[Michael Gebhardt]

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

[Melanie_Giuliani]

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

[Melanie_Giuliani]

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

[Michael Gebhardt]

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

[Michael Gebhardt]

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

[Michael Gebhardt]

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)

[Keith Puzey]

Hi Michael,

 

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

 

Regards

Keith

[Michael Gebhardt]

Hi Keith,

 

 

I created case 00613851

 

Best regards

Michael

[Keith Puzey]

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

[Michael Gebhardt]

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

[Keith Puzey]

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

[Michael Gebhardt]

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

[Keith Puzey]

Hi Michael,

 

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

 

Regards

Keith

[Michael Gebhardt]

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