Analyze 4.3.5 + SSL connection (from AN 9.3 and from and endpoint Browser)

[jormagonse]

Hi team!

I have the following situation

The IP registered by the Log&Audit plugin is that of the Analyze server and not that of the endpoint. When the connection is HTTPS (https:///opal), it do not log the IP of the endpoint.

When the connection is not HTTPS (http://:9082/opal), it does log the IP of the endpoint.

Any advice you can give me to solve this?

Best regards!

[Anthony-Johnson-i2]

Hi Jormagonse

I would not have thought that SSL/TLS would change what IP address was logged from client to server as it encrypts the data being transferred not the meta data about the connection.

Is there any other difference between what you are logging when you see the IP address and what you are logging when you do not or where it is coming from?

For example is one coming from the ANBP thick client app on the client machine while the other is coming from a browser based application like i2 Investigate or i2 Notebook?

Is one call coming directly to the server while the other is going via another route that may be altering the headers like a proxy server or VPN?

Can you do , or have you done, a test case where the client IP is logged and then the the server IP is logged where it is exactly the same action being made from the same end point application with the only difference being SSL enabled or not for the connection?

Cheers

[Anthony-Johnson-i2]

I had a chat with one of our developers regarding this, and the call we use to get the Client IP address would return the Internet Protocol (IP) address of the client or might return the IP of the last proxy or load balancer that the request was routed through. So if your SSL route us going via a load balancer or proxy server then the IP address might end up being where that is sending the request on from and not that of the originating client/user.

If this is what is happening for you, then depending on what set up you are using you may be able to configure things in that network infrastructure so that the original Client IP is passed through but that will depend on what route your request is taking and what network infrastructure it is passing through from the client to the i2 Analyze server.

As you do not include a port number in your HTTPS URL you are showing, that would suggest that something else is re-routing the request to us.

Cheers

[jormagonse]

Hi Anthony My Answers: Is there any other difference between what you are logging when you see the IP address and what you are logging when you do not or where it is coming from? For example is one coming from the ANBP thick client app on the client machine while the other is coming from a browser based application like i2 Investigate or i2 Notebook?

Answer: The only difference found is in CLIENT USER AGENT Query result through i2Notebook on Analyze Server (localhost/HTTP) ID: 26 USER NAME: i2user DATE: 05/10/2022 TIME: 11:07:50 USER SECURITY GROUPS: Analyst USER SECURITY PERMISSIONS: [SD-SL: [CON: UPDATE, UC: UPDATE], SD-SC: [HI: UPDATE, OSI: READ_ONLY]] CLIENT USER AGENT: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 CLIENT IP ADDRESS: 127.0.0.1 REC: TESTID: 2.1, DataStore: Information Store, OriginIds: [{"type":"OI.ANB","keys":["5233065a103a5a48b40cc2c5d407008d"],"itemTypeId":"ET1"},{"type":"OI.IS","keys":["4f716908-e08b-49f8-825a-70a84a690b21","ET1","1"],"itemTypeId":"ET1"}], RecordIdentifier: G3oWvYpHQDw6uGpPYLxeKk9tvL

Result of the query through AN9.3 on the endpoint(http://:9082/opal)

For example is one coming from the ANBP thick client app on the client machine while the other is coming from a browser based application like i2 Investigate or i2 Notebook?

Answer: The only difference found is in CLIENT USER AGENT

Result of the Query through the i2Notebook in the endpoint (HTTPS):

ID: 23 USER_NAME: i2user DATE: 05/10/2022 TIME: 10:44:58 USER_SECURITY_GROUPS: Analyst USER SECURITY PERMISSIONS: [SD-SL: [CON: UPDATE, UC: UPDATE], SD-SC: [HI: UPDATE, OSI: READ_ONLY]] CLIENT USER AGENT: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 Edg/106.0.1370.34 CLIENT IP ADDRESS: 192.168.100.199 REC: TESTID: 2.1, DataStore: Information Store, OriginIds: [{"type":"OI.ANB","keys":["5233065a103a5a48b40cc2c5d407008d"],"itemTypeId":"ET1"},{"type":"OI.IS","keys":["4f716908-e08b-49f8-825a-70a84a690b21","ET1","1"],"itemTypeId":"ET1"}], RecordIdentifier: G3oWvYpHQDw6uGpPYLxeKk9tvL

Query results through AN9.3 on the endpoint (HTTPS): ID: 24 USER_NAME: i2user DATE: 05/10/2022 TIME: 10:57:27 USER SECURITY GROUPS: Analyst USER SECURITY PERMISSIONS: [SD-SL: [CON: UPDATE, UC: UPDATE], SD-SC: [HI: UPDATE, OSI: READ_ONLY]] CLIENT USER AGENT: Mozilla/5.0 (Windows 10.0; Win64; x86) Chromium/94.0.4606.61 ANB/9.3.1.342 CLIENT IP ADDRESS: 192.168.100.199 REC: TESTID: 2.1, DataStore: Information Store, OriginIds: [{"type":"OI.ANB","keys":["5233065a103a5a48b40cc2c5d407008d"],"itemTypeId":"ET1"},{"type":"OI.IS","keys":["4f716908-e08b-49f8-825a-70a84a690b21","ET1","1"],"itemTypeId":"ET1"}], RecordIdentifier: G3oWvYpHQDw6uGpPYLxeKk9tvL

Is one call coming directly to the server while the other is going via another route that may be altering the headers like a proxy server or VPN?

Answer: No, we do not use a proxy, nor a VPN connection. We test them on VMs on the same physical host, on the same network segment.

Can you do , or have you done, a test case where the client IP is logged and then the the server IP is logged where it is exactly the same action being made from the same end point application with the only difference being SSL enabled or not for the connection?

Answer: It is correct, in all cases a quicksearch of the entity called TEST is performed and it is added to a chart.

[jormagonse]

I had a chat with one of our developers regarding this, and the call we use to get the Client IP address would return the Internet Protocol (IP) address of the client or might return the IP of the last proxy or load balancer that the request was routed through. So if your SSL route us going via a load balancer or proxy server then the IP address might end up being where that is sending the request on from and not that of the originating client/user.

Answer: We do not use PROXY, nor balancers.

If this is what is happening for you, then depending on what set up you are using you may be able to configure things in that network infrastructure so that the original Client IP is passed through but that will depend on what route your request is taking and what network infrastructure it is passing through from the client to the i2 Analyze server.

Answer: The connection is direct, in the same network segment, all the ANALYZE components are in a single server.

As you do not include a port number in your HTTPS URL you are showing, that would suggest that something else is re-routing the request to us.

Answer: The HTTPS port is 443 (Default configuration in the IBM HTTPServer, automatically generated by the Deploy process)

[Anthony-Johnson-i2]

Hi

Jormagonse

So on the same server you have : IBM HTTPServer software running i2 Analyze + Liberty Server software running

You run your search from a separate machine.

When you do not use SSL you contact the i2 analyze application running in Liberty directly on its port 9082.

When you use SSL you do not give the direct port for the i2 Analyze application running in Liberty, you use the default 443 port that the IBM HTTPServer software is listening on.

Even though the IBM HTTPServer is on the same machine as the Liberty application server the IBM HTTP server will then forward the request it receives from your client machine itself on to our i2 Analyze application that is running in Liberty.

So when you use SSL you are passing through the IBM HTTP server software which is acting as a proxy server and then routing the same request on to our software.

This is extra step in the communication path between your client and our i2 Analyze application in Liberty through the IBM HTTPServer software is quite likely to be what is causing the call we use to get the IP of the client machine to be told that the IP address is the one for the IBM HTTPServer sending on the request which as you have said is the same as that of the Liberty server running i2 Analyze.

[Anthony-Johnson-i2]

An HTTP server is not required for i2 Analyze if you are using an HTTPS connection. (We do unfortunately still document one being used in our online documentation though at the moment).

So if you do not have another reason for having an HTTP server on the Liberty and i2 Analyze machine you can set up for HTTPS /SSL access without it. That of course might not be possible depending on the restrictions of the network.

You can check to see what IP address is logged in the HTTPServer for the request and that is quite likely to be the client one you are expecting.

Cheers

[jormagonse]

So on the same server you have : IBM HTTPServer software running i2 Analyze + Liberty Server software running

You run your search from a separate machine.

When you do not use SSL you contact the i2 analyze application running in Liberty directly on its port 9082.

When you use SSL you do not give the direct port for the i2 Analyze application running in Liberty, you use the default 443 port that the IBM HTTPServer software is listening on.

Even though the IBM HTTPServer is on the same machine as the Liberty application server the IBM HTTP server will then forward the request it receives from your client machine itself on to our i2 Analyze application that is running in Liberty.

So when you use SSL you are passing through the IBM HTTP server software which is acting as a proxy server and then routing the same request on to our software.

This is extra step in the communication path between your client and our i2 Analyze application in Liberty through the IBM HTTPServer software is quite likely to be what is causing the call we use to get the IP of the client machine to be told that the IP address is the one for the IBM HTTPServer sending on the request which as you have said is the same as that of the Liberty server running i2 Analyze.

Answer: I understand, the IBM HTTP Server is IP masking. I use it this way because the documentation on how to implement an SSL connection from the endpoint to the ANALYZE uses it. Is there any other documentation that can help me to use SSL connection without the HTTP Server?

[jormagonse]

An HTTP server is not required for i2 Analyze if you are using an HTTPS connection. (We do unfortunately still document one being used in our online documentation though at the moment). :( So if you do not have another reason for having an HTTP server on the Liberty and i2 Analyze machine you can set up for HTTPS /SSL access without it. That of course might not be possible depending on the restrictions of the network.

Answer: I have no special reason, the reason I use the IBM HTTP Server is that I have followed the available documentation to implement an SSL connection.

You can check to see what IP address is logged in the HTTPServer for the request and that is quite likely to be the client one you are expecting.

Answer: I have reviewed the Apache logs and they do not register any IP (neither of the server nor of the endpoint)

[jormagonse]

This is the documentation I followed:

• https://docs.i2group.com/analyze/4.4.0/c_ssl_all_intro.html
• https://docs.i2group.com/analyze/4.4.0/c_creating_keystores.html
• https://docs.i2group.com/analyze/4.4.0/c_kc_intro_ssl.html
• https://docs.i2group.com/analyze/4.4.0/t_sec_client_http.html Regards

[Anthony-Johnson-i2]

Hi Jormagonse

The requests made through the HTTP server can usually be seen in its Access log but what actually gets logged there would depend on how that has been configured.

The documentation you followed is what we currently have online, and as you have SSL working using that set up you followed it correctly.

When we were we still shipping the Analysis Repository as well as the Information Store, the HTTP server was needed to route messages for that side of i2 Analyze but as we now only use the Information Store, it is surplus to requirements from our perspective.

Unfortunately, our documentation is not as up to date as the product in this area. I raised this as an issue earlier on in the year and updated documentation to show how to do this without an HTTP Server should be available in a future release.

If an HTTPServer is not involved in the route from the client to the Liberty server then to have a secured connection, you would secure Liberty for SSL and establish trust between that and your clients rather than between that and the HTTPServer.

I have not personally configured our system for direct secured access without the HTTP server, so I am not familiar with the details.

As we have determined that this is not actually an i2 Auditing plug in issue, but is to do with the originating IP address being masked by the HTTPServer, then your options are either to look in to how to configure the HTTPServer so that it does forward on the original IP address for the client, or how to secure direct SSL access from the client to the Liberty server. (Moving forward I expect trying to do this without the HTTPServer is the best choice).

This is the IBM Documentation for setting Liberty up for SSL:

Enabling SSL communication in Liberty

If you need more help in getting your deployment working without the HTTP Server, then seeing as our documentation is lacking, you should be able to raise an official Support case for help in securing the system using SSL.

Cheers

[jormagonse]

Thank you

[jormagonse]

We will test the recommendation later