Actually that unknown port was created in ofbiz code. *(Everything I do for these guys is stuff they haven't been able to solve in time, so I have to assume they've tried all the obvious solutions - I do get your point though, a greater level of collaboration and access to their systems, along with the context of an issue would be great but .. that's just not my reality) *
RMI RenewClean-[127.0.1.1:46251 ,org.ofbiz.service.rmi.socket.ssl.SSLClientSocketFactory used visualvm to get a class name for the thread listening on that port. commenting out framework/base/config/ofbiz-containers.xml > RMI Service Dispatcher <container name="rmi-dispatcher" class="org.ofbiz.service.rmi.RmiServiceContainer"> ... Removes that one. In default OFbiz 10.04 (I've been running locally) In their version though there is 1 additional unknown listening port (also related to RMI RenewClean)... problem is it's I'm stumped about how to remove it ... since I've already disabled the ' RMI Service Dispatcher' "RMI RenewClean-[127.0.1.1:45136]" daemon prio=10 tid=0x00007f0640004800 nid=0x25d3 in Object.wait() [0x00007f0616536000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000c4582ec0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135) - locked <0x00000000c4582ec0> (a java.lang.ref.ReferenceQueue$Lock) at sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:535) at java.lang.Thread.run(Thread.java:745) On Thu, Feb 12, 2015 at 5:50 PM, Ron Wheeler <rwhee...@artifact-software.com > wrote: > Those are Apache, Tomcat or Jetty ports and are not in your code. > Your sysadmins should know that from the configuration of services on the > host and a bit of Google. > > Depending on the deployment configuration, some of these should be > accessible through the firewall if they want people outside the local > network to access OFBiz (eCommerce for example) > If there is an Apache Proxy in the mix 8080 and 8009 should not be visible > from outside. > AJP should not as it typically is used to communicate between a front-end > HTTP server and a Java servlet container (Tomcat , Jetty, etc) > I would block RMI as well. > > The easy thing to do is block them all at the firewall and see what fails. > If OFBiz is not accessible. open 8080 first and see if that fixes the > problem. > I doubt if the rest should be accessed from outside the firewall. > If there is an HTTP (Apache usually) proxy, 8080 will not be needed. > > To make a better guess, one would need to know the deployment architecture > (services running, user access and locations in the network, etc.) > > Ron > > > On 12/02/2015 10:27 AM, Justin Robinson wrote: > >> Ron, >> Thanks it wasn't making much sense to me either. Just spoke to the system >> admin who reported this issue. I'm not really sure what their actual issue >> is or what security concerns are. I don't do sys administration at all. >> >> For whatever reason they want to know what this port is for. I'm guessing >> it's related to an onsite deployment customer's firewall policy issue. >> >> example 1: >> >> root@justdev:/home/justin# netstat -tlnp | grep java >> >> tcp6 0 0 :::8009 :::* LISTEN 2097/java ( AJP port) >> >> tcp6 0 0 127.0.0.1:53161 :::* LISTEN 11015/java (admin) >> >> tcp6 0 0 :::1099 :::* LISTEN 2097/java (RMI port) >> >> tcp6 0 0 :::8080 :::* LISTEN 2097/java (http port) >> >> tcp6 0 0 :::8443 :::* LISTEN 2097/java (https port) >> >> tcp6 0 0 :::42526 :::* LISTEN 2097/java (Unknown) >> >> >> example 2: >> >> root@justdev:/home/justin# netstat -tlnp | grep java >> >> tcp6 0 0 :::8009 :::* LISTEN 2401/java ( AJP port) >> >> tcp6 0 0 127.0.0.1:53161 :::* LISTEN 11015/java (admin) >> >> tcp6 0 0 :::1099 :::* LISTEN 2401/java (RMI port) >> >> tcp6 0 0 :::8080 :::* LISTEN 2401/java (http port) >> >> tcp6 0 0 :::8443 :::* LISTEN 2401/java (https port) >> >> tcp6 0 0 :::50365 :::* LISTEN 2401/java (Unknown) >> >> Their developers tried to find it in the code and failed. I just went and >> put break points in likely classes where java.net.ServerSocket is used & >> checked the variable values to try locate the elusive code. No luck. >> >> Even a suggested method on how to locate the code would be helpful. Any >> idea of a class likely to be used to produce this unknown port that I >> could >> search for. >> >> >> >> >> >> >> On Thu, Feb 12, 2015 at 4:09 PM, Ron Wheeler <rwheeler@artifact-software. >> com >> >>> wrote: >>> This discussion belongs in the user forum. >>> >>> I am not sure about the security implications of allowing a local app to >>> access a database on the same machine. >>> I am not an expert on IPv6 but those are all localhost to localhost >>> connections. >>> >>> Do they have a specific threat in mind? >>> >>> The usual protection steps are: >>> 1) Not to allow unknown programs to run on the server >>> 2) protect 3306 from external access using the firewall/router >>> 3) Protect SSH access to prevent outside users from accessing the server >>> or don`t run sshd >>> 4) Use sensible passwords on database access. >>> 5) Intrusion detection (fail2ban, logging) >>> >>> Closing process to process communication within a server is hardly ever >>> considered as a security step. >>> I am not sure that there is any way in Linux to restrict which process >>> can >>> access a port on localhost aside from connection control (passwords- 4 >>> above) or any way to know what ports the client process will use to >>> connect >>> to 3306. >>> >>> I think that the higher numbered ports are dynamically allocated so >>> closing them will be like playing Wack-A-Mole (close one and the system >>> will find another one that works) but it could just cause the client to >>> hang depending on how the code handles a time-out on a connection - wait >>> forever, throw an exception or try another port. >>> >>> It would seem that closing them would stop access to the database. >>> >>> Try it and see but I am pretty sure that the results will be >>> unsatisfactory. >>> >>> It is hard to see the security issue and the steps above will provide a >>> high level of security >>> >>> I hope that this helps. >>> Ron >>> >>> >>> On 12/02/2015 5:41 AM, Justin Robinson wrote: >>> >>> I've been searching the mail archives for some clues as to the purpose >>>> of >>>> these dynamically generated 5 digit open ports. Maybe I'm using the >>>> wrong >>>> search terms but haven't been able to find a hint. >>>> >>>> My client's client wants them closed for security purposes. >>>> My client has been unable to find them in the code or documentation and >>>> I >>>> gather they've spent some time looking. >>>> >>>> Since it my client's OFbiz code base has been heavy modified, I just ran >>>> OFbiz version 10.04.06 and I just get >>>> >>>> tcp6 0 0 127.0.0.1:53161 :::* >>>> LISTEN >>>> 1000 21364148 11015/java >>>> tcp6 0 0 127.0.0.1:34898 127.0.0.1:39096 >>>> ESTABLISHED 1000 22201512 13441/java >>>> tcp6 0 0 127.0.0.1:39096 127.0.0.1:34898 >>>> ESTABLISHED 1000 22197002 11015/java >>>> tcp6 0 0 127.0.0.1:58250 127.0.0.1:3306 >>>> ESTABLISHED 1000 22225165 13456/java >>>> tcp6 0 0 127.0.0.1:58251 127.0.0.1:3306 >>>> ESTABLISHED 1000 22223602 13456/java >>>> tcp6 0 0 127.0.0.1:58246 127.0.0.1:3306 >>>> ESTABLISHED 1000 22205538 13456/java >>>> tcp6 0 0 127.0.0.1:58253 127.0.0.1:3306 >>>> ESTABLISHED 1000 22225166 13456/java >>>> tcp6 0 0 127.0.0.1:58252 127.0.0.1:3306 >>>> ESTABLISHED 1000 22223603 13456/java >>>> >>>> The list is similar in that most foreign addresses are the database >>>> server. >>>> Does anyone know where I can find the code that opens them and more >>>> importantly what effect closing them might have on OFbiz functionality? >>>> >>>> >>>> -- >>> Ron Wheeler >>> President >>> Artifact Software Inc >>> email: rwhee...@artifact-software.com >>> skype: ronaldmwheeler >>> phone: 866-970-2435, ext 102 >>> >>> >>> > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >
