Re: OFbiz version 10.04.06 - dynamically generated 5 digit open ports

[Ron Wheeler]

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: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Justin Robinson]

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 <[hidden email]
> 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: [hidden email]
> skype: ronaldmwheeler
> phone: [phone], ext 102
>
>

[Ron Wheeler]

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 <[hidden email]
>> 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: [hidden email]
>> skype: ronaldmwheeler
>> phone: [phone], ext 102
>>
>>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Justin Robinson]

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 <[hidden email]
> 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: [hidden email]
>>> skype: ronaldmwheeler
>>> phone: [phone], ext 102
>>>
>>>
>>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: [hidden email]
> skype: ronaldmwheeler
> phone: [phone], ext 102
>
>