Recheck exposed ports on Beckn ONIX installations

[vbabuEM]

Currently components installed with Beckn ONIX expose several ports on the localhost. In one of the installations in Brazil, some malware was misusing the Redis instance by contacting the host on the exposed port (6379)

In many cases, these ports do not need to be exposed on the host. It is sufficient if it is available on the docker network. For example, the redis/rabbit installed as part of BAP is used only by BAP Client and BAP Network. It is not really used outside of these two. So as long as the redis instance is accessible on the docker network, it is sufficient. It is not required to be exposed on the host. There might be some cases where this is required for management/monitoring software. If it the case, we should document it and also evaluate if we need to make the default as non-exposed, if such monitoring is a rare usecase.

Check all the ports exposed on host in Beckn ONIX and individually evaluate if it is required to be done that way.

[viraj89]

To identify which all ports are exposed, document them and also update the Onix documentation. @prasad-takale-eminds

[vbabuEM]

@viraj89 , @prasad-takale-eminds , this is not a documentation issue. It is a security issue. For installations where the redis is used only on the docker network, we should not expose it on the host. There was a issue in one of the customers that somehow this exposed port was misused by some malicious code.

[prasad-takale-eminds]

@vbabuEM All the ports are currently exposed at the host level, and we access our application through an Nginx proxy pass configuration. If needed, we can change the default ports of all supporting applications and update the default.yml file accordingly.

Additionally, we are not opening any additional ports on the Security Group (SG). We only need ports 443 and 80 to be open:

• Port 443 is for accessing the application via HTTPS.
• Port 80 is for obtaining the Let's Encrypt SSL certificate.

I have double-checked all application files to ensure there are no unnecessary open ports.

[vbabuEM]

The issue was primarily in the non-horizontal scaling configuration. Basically since the containers access the port over the docker network, there is no need to expose them at the host level. There was one incident in Brazil (I have documented it in description), which prompted this. In the horizontal-scalability case, this will not be relevant. There you have to expose it over the vpc for the PS pods to access it.

[yesrag2309]

@emmayank - As we discussed in todays syn up call the review is pending the @vbabuEM . Kindly talk with him and do the needful.

@viraj89 @faizmagic

[vbabuEM]

I have written everything in the comments and discussion above. However if you still have doubts, please ping me.

[yesrag2309]

@emmayank - Please refer above for @vbabuEM comment if there is anything please check with him and close the card accordingly @viraj89 @faizmagic @prasad-takale-eminds

[emmayank]

@prasad-takale-eminds - Basically a security audit of the docker-compose.yml to see if we need to expose ports on the localhost or just exposing them on the docker network is sufficient. If we do not need to expose on the localhost (in the non-horizontal scale deployment), we should remove those lines from docker-compose.yml