Issue
Nmap scan report for 135.87.96.34.bc.googleusercontent.com (XXX.XXX.XXX.XXX)
Host is up (0.016s latency).
Not shown: 962 filtered ports
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE
25/tcp open smtp
43/tcp open whois
80/tcp open http
83/tcp open mit-ml-dev
84/tcp open ctf
85/tcp open mit-ml-dev
89/tcp open su-mit-tg
110/tcp open pop3
143/tcp open imap
443/tcp open https
465/tcp open smtps
587/tcp open submission
700/tcp open epp
993/tcp open imaps
995/tcp open pop3s
1084/tcp open ansoft-lm-2
1085/tcp open webobjects
1089/tcp open ff-annunc
1443/tcp open ies-lm
1935/tcp open rtmp
3389/tcp open ms-wbt-server
5222/tcp open xmpp-client
5432/tcp open postgresql
5900/tcp open vnc
5901/tcp open vnc-1
5999/tcp open ncd-conf
8080/tcp open http-proxy
8081/tcp open blackice-icecap
8085/tcp open unknown
8086/tcp open d-s-n
8088/tcp open radan-http
8089/tcp open unknown
8090/tcp open opsmessaging
8099/tcp open unknown
9100/tcp open jetdirect
9200/tcp open wap-wsp
20000/tcp open dnp
30000/tcp open ndmps
Nmap done: 1 IP address (1 host up) scanned in 399.73 seconds
Environment
- Liferay SaaS
Resolution
The explanation for unexpected open ports is because projects are on a shared cluster. The firewall rules are shared between all projects on the shared cluster. This means the port can be exposed due to another project's services.
While the port appears open, the service on the cluster which is responsible for their external IP will not forward any request to their services for those ports that are not exposed on their LCP.json, even though the port is open on the firewall rules.
If the port is marked as external: true request will be allowed to be attended.
If port is not marked as external, request will get filtered.