tracker issue : CF-4141711

select a category, or use search below
(searches all categories and all time range)
Title:

Monitoring Server Listens to Port 5500 even when disabled from Admin

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/Fixed

Reporter/Name(from Bugbase): Paul Cassar / Paul Cassar (Godwin Schembri)

Created: 04/19/2016

Components: Server Monitoring

Versions: 2016,11.0,2018

Failure Type: Incorrectly functioning

Found In Build/Fixed In Build: CF11_Final / 2018.0.0.313895

Priority/Frequency: Normal / Some users will encounter

Locale/System: English / Linux RHEL 6.4

Vote Count: 4

Problem Description:
Port ‘5500’ is available even though the Server Monitoring > Monitoring Settings > ‘Enable Monitoring Server’ from the administrator console is switched off. This feature works correctly on ColdFusion 9 and ColdFusion 10, the issue seems to be on ColdFusion 11 only. Issue has been tested on a fresh instance of ColdFusion 11 as well as with ColdFusion 11 containing update 7. 
As soon as the .ear file is undeployed the port is no longer available. When changing the IP address or port from the jetty.xml, the respective port is updated for the Monitoring Server Port, and thus it is being used by the Jetty service. An additional test was to listen to port ‘5500’ and the Monitoring Server Port is dynamically assigned to a new port. In ColdFusion 10 it used to give the error message that Port is already in use. As can be seen in the screenshots below the port is available even though the Enable Monitoring Server checkbox is unchecked.


Steps to Reproduce:
1. Do deploy earfile
2. Access the 'Monitoring Settings' > Make sure the 'Enable Monitoring Server ' is unchecked.
3. Check port 5500
4. Port will be open even the Monitoring Server is switched off.

Actual Result:
Port 5500 remains open - Refer to the 'Add Note' section for my questions.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	4141711

External Customer Info:
External Company:  
External Customer Name: Godwin Schembri
External Customer Email:  
External Test Config: My Hardware and Environment details:

Application Server: JBoss Enterprise Application platform 6.3

ColdFusion 11 Update 7

Attachments:

  1. April 19, 2016 00:00:00: 1_Screenshot.png

Comments:

https://bugbase.adobe.com/index.cfm?event=bug&id=CF-3837342 https://bugbase.adobe.com/index.cfm?event=selectBug&CFGRIDKEY=CF-4130808 I am aware that the above issues point to the same problem thus this can be considered as a duplicate, however I disagree the issue is closed as no proper explanation is given, thus please address the below points which mainly reference to bug id: CF-3837342 answer. 1. What 'other service' are making use of this port? 2. According to the reply: 'in order to avoid confusion this port number information is removed from the Monitoring Settings Admin page' the port should have been removed from the Server Monitoring > Settings page but it is still visible, as can be seen in the screenshot, should this be the case? 3. If more than once ColdFusion instance is running on the application server, the port used is another, therefore if the 5500 is used by another instance, another port is used, is there a list which we can follow or set in order to set the available ports or is this completely dynamic and we have no control over?
Comment by External U.
3036 | April 19, 2016 07:23:21 AM GMT
Hi Godwin, 1. 5500 is used by Jetty server shipped with CF. It is been used by html to pdf feature. 2. That change has been done in CF2016 3. Yes the port picked up is completely dynamic and we have no control over it. Thanks, Dattanand Bhat
Comment by Dattanand M.
3037 | June 15, 2016 01:23:24 AM GMT
Hi Dattanand, Thanks for your reply. We use cfdocument for our pdf pages, we are not using cfhtmltopdf are we impacted should we opt to turn of the Getty Service? Are there any plans from Adobe to produce a hotfix containing the functionality to turn off the Getty service if not in use as per point 2 in the thread? Thanks again
Comment by External U.
3038 | July 04, 2016 08:09:26 AM GMT
Hi Dattanand, Was there any progress on this issue? Thanks.
Comment by External U.
3039 | August 03, 2016 02:34:54 AM GMT
Hi Godwin, We are not fixing this for now. We will reevaluate this if we get more request for the same. Thanks, Dattanand Bhat
Comment by Dattanand M.
3040 | August 03, 2016 05:50:13 AM GMT
@Godwin, turning this off might affect multiple other features (imaging, graphs,content-based PDF's, cfpresentation, cfreport etc), hence, we will not be fixing this. Let us know if you still have some concerns.
Comment by Vamseekrishna N.
3041 | August 24, 2016 01:17:19 AM GMT
@Vamseekrishna / @Dattanand - the PDF service, solr service use port 8987 by default, and is configured in the jetty sub folder of the CF instance. The jetty server that runs on port 5500 is not started by the ColdFusion Add on Service is it started by the main CF process. It is configured in the cfusion/lib/jetty.xml file. So there are two different jetty servers. The imaging, graphs, cfpresentation and cfreport utilize the /CFFileServlet/ to serve dynamically generated assets, which is mapped to the main web.xml I don't think your answer is correct about what the server on port 5500 is doing. Please look into this further! Also how can it not be a bug to have a setting in ColdFusion Administrator that says "Enable Monitoring Server" and does not do anything? If you are really correct that it is a requirement to run the monitoring server to use other features (which I am skeptical is actually the case) then you need to remove the setting to avoid confusion.
Comment by Peter F.
3042 | October 05, 2017 02:56:14 PM GMT
It is a bug to have a setting in ColdFusion Administrator that says "Enable Monitoring Server" and does not do anything? If you are really correct that it is a requirement to run the monitoring server to use other features (which I am skeptical is actually the case) then you need to remove the setting to avoid confusion.
Vote by Peter F.
3045 | October 05, 2017 02:57:25 PM GMT
@vamseekrishna / @dattanand - Pete is doing the diligence for you that your team should be doing. I have confirmed the same on all my CF11 servers. The main CF service is responsible for jetty running on 5500, even though Enable Monitoring Server is disabled. Secondly, I see no new jetty server on any other port if I DO enable Monitoring Server. I would really like to hear a more detailed answer to Pete's question above, as he has clarified why your previous answer was not correct. Unknown servers running on undefined ports does not speak well of your security posture...
Comment by Nikolas S.
3043 | October 12, 2017 12:06:32 AM GMT
Won't Fix is an unacceptable answer to this bug.
Vote by Nikolas S.
3046 | October 12, 2017 12:08:22 AM GMT
@Peter - By default the monitoring service uses 8500, by enabling "Enable Monitoring Server" option from CF admin monitoring service uses 5500. However, PDFg service also uses the same jetty server to serve temporarily generated HTML files. We are evaluating how we can decouple these services.
Comment by Dattanand M.
3044 | October 16, 2017 05:02:45 AM GMT
Dattanand, you keep saying that port 5500 is used by the PDFG service. As Pete has explained, it is not. It's understandable how someone could fear that it may be related, since both are indeed based on Jetty, but again as Pete has pointed out, they are TWO DIFFERENT JETTY IMPLEMENTATIONS. For those interested in the history, CF9.0 had added Solr, enabled by way of the then "jetty service" (since renamed "add-on service", and used also now by the PDFG featrure), and that was implemented as a separate service/jvm to separate such operations off of the CF JVM. Then in CF 9.0.1, the new "monitoring server" option was added to the Server Monitor (along with the new "monitoring settings" page in the admin), to enable requests to the Server Monitor to be able to be talked to by other than the external web server or CF's built-in web server. Since that had to be enabled WITHIN the CF JVM, that was implemented as this second jetty implementation. But as has been reported here, the exposure of that jetty web server (and port 5500) has been a problem. Still another problem is that it's set by default to listen with a "host" value of 0.0.0.0, so it listens to requests from any IP. That has been a problem when people have nessus and other security scans that blast away at that port and lead to CF itself locking up (since again, THAT port is indeed setup WITHIN the JVM underlying CF). There are still more reasons why this must be addressed. For one, this jetty web server (inside of CF) is enabled even in CF Standard implementations, which DO NOT EVEN HAVE the CF Server Monitor feature in CF2016 and below. Furthermore, this port (and the same cfusion/lib/jetty.xml and its port and host values) REMAIN enabled even in CF2018 which (for Std AND Enterprise) NO LONGER HAS the CF Server Monitor anymore. For all these reasons, this should be addressed. This jetty web server should certainly be disabled if the CFSM "monitoring server" feature is turned off. And it should NOT be enabled by default on CF Standard (2016 and below), or in CF2018 at all. Indeed, it should not even be enabled by default in CF2016 Enterprise and below UNLESS someone turns on the "monitoring server" feature. It seems somehow someone decided to enable it always, regardless of any of these circumstances, which is a problem for all the reasons above.
Comment by Charlie A.
29629 | August 28, 2018 09:27:09 PM GMT
We had the Nessus port 5500 security scan problem locking up CF that Charlie mentioned in his comment. It was a big problem well beyond what average users should have to encounter. We felt lucky that Charlie was able to identify the problem and tell us how to work around it.
Vote by John D.
29630 | August 28, 2018 10:19:49 PM GMT
Adobe folks, I see this indicating fixed in cf2018, which is great. But why didn't anyone respond to it to clarify things? Are there corrections to info you shared previously? It would help for all concerned to know the situation. Also, the info here says it was fixed in 2018.0.0.313895, which implies it was in the base release. But then the bugs fixed list for its update 2 points to this bug, so what's the difference between what was done per the first release and the second update, if anything?
Comment by Charlie A.
30291 | February 17, 2019 03:04:41 AM GMT