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