We Keep Coding

How to find the TCP/UDP port used by a specific process on a given remote machine

I have an issue I can't manage to solve.
What I know :
Some information about the process I'm looking for : It's a java process but if I have access to information similar to what's in ps -ef | grep java, then I can find it's PID.
The IP address of a remote machine running Linux version 3.16.7-35-desktop (SUSE Linux)
I would like to find the port used by that process on that machine, with some constraints :
Must be done programmatically, in java
Must work from Windows and Linux (if needed, the java code could handle both cases separately)
Doesn't require to install any other application (neither on the caller machine nor on the remote one)
I also know the port should be between 10000 and 20000. I have network access to the remote machine (both machines are on the same subnet).
How would you do that ?
Note : I found this, but it's old and not remote.

This is a standard hacking requirement. You can do do what nmap does.
Connect to every port in the range in turn and try to determine which the service is this listens to or responds to that port based on the data you get from the service as you connect. It is very slow and will look like a hack if you have any tools to detect this, but it is a technique which has been in use for a long time as it is the only way to do this without a service to tell you what is running on that machine.
A much better approach is to have a service discover process somewhere which has all the services you can contact, ideally with their status so you can easily find one which is available to your client.

Java JMX Server

I'm curious about how JConsole and JMX work together. Specifically, I have read this JConsole Guide which mentions that
jconsole uses a JMXConnector client to connect to the JMXConnectorServer in
the target application. If the application isn't started with the JMX agent
then there isn't a JMXConnectorServer and jconsole doesn't have anything to
connect too. In that case it uses a HotSpotTM VM specific mechanism to start
the JMX agent in the target VM. Once the agent is started then jconsole connects
as normal.
When I start jconsole it simply needs a port and hostname for the JMX information, so I'm wondering if its possible to access the MBeans through any arbitrary tcp connection (and thus any programming language), or if there is something special that jconsole is also doing?
I know how to access the MBean Factory though java, but I am curious if I can access these items through an arbitrary language via TCP or another straightforward mechanism. Also see link discussing rest connector.

By default, the JMX server provides connection via RMI. That will make it tricky to access the server through an arbitrary language.
However, the JMX server is not limited to RMI as the communication protocol. The architecture is extensible and pretty much any transport protocol might be used - but it would need to be written almost from scratch.
Take a look at Jolokia - they do a pretty amazing stuff to let you talk to the MBean servers via a bunch of protocols (REST is one of them), amongst other things.

How can I determine if another local machine is alive?

Is it possible to make my local computer function as a gateway in Java? I need the other local machines to connect directly to my computer to see if they are alive or not.

You could run a Java server program on your desired PC and let it listen on a port. Then you could use other programs (browser, other Java programs etc.) to connect to this port, and send commands to be executed by the Java server program.
If you just want to see if the PC is turned on or not, I'd just use the ping command though. Or see this answer: How to do a true Java ping from Windows?

Surely it's the other way round? Surely you want to connect to the other machines to see if they're alive? In which case see InetAddress.isReachable().

Try this.
Create a Java Server Socket, which keeps listening to the client at some port.
Write a client in Java which connects to the Server, wrap the connection logic in try-catch block....
If your host is alive the try code is executed which contains the code to connect to the
Server, if this connection process fails you will get UnknownHostException, here you can instead type a message that the connection failed.

You could more easily manage and control this by polling for other devices from a central server. If possible, avoid unnecessary client/agent apps that might tax your development and support resources as well as taking up RAM on the client workstations.
There are many monitoring tools that already do what you want. I'd have a look at Nagios, for example.
If you want to develop your own app, do your own quick troubleshooting, or just get a feel for network discovery tools, then take a look at NMAP. You could, for example, search a subnet for anything that responds to TCP:445 and see what Windows machines are alive.

If you do go the Nmap route, please have a look at Nmap4j on Sourceforge. It's a Java wrapper API that simplifies the work needed to integrate Java and Nmap.
Cheers!

Is it possible to access the different ports on a web server?

I created a game and I want to put it on online. I want to buy a website (I'll probably use goddaddy to buy a domain name and use them as the web host) to use as the server to handle game play. Because I would need a separate server for each game, I would need each game's server to exists on different ports. So this leads to my question, is is possible to access these ports on my future web server? (I wrote the program in Java, so I would assume that I would access the ports from the server side by choosing a port for a ServerSocket, and from the client side by using the IP address from the website and the chosen port for a Socket)
(note: also, I am aware that it may be easier to simply use one port and run the servers on different threads instead, but I am just curious to have my question answered)
thanks a lot,
Ian

Technically it is possible to use different ports, but I don't think that a webhoster like goddaddy will let you run a java process that binds to a special port.

If you mean that you are going to create your own TCP server you obviously can create as many instances of your server and configure them to listen to different ports. But it is year 2011 now. This solution was OK in early 90s.
I'd suggest you to use Restful API that works over HTTP. In this case you can forward calls to server side of each application using URL, e.g.
http://www.lan.com/foo/login?user=u123&password=123456 - log in into application foo
http://www.lan.com/bar/login?user=u123&password=123456 - log in into application bar
In this case you need only one server (the web server) that is listening to socket (port 80).
Your server side implementation could be done using various web techonlogis (php, java, asp.net etc) on your choice.

Yes, that should work. The security manager permits connections to a different port on the same IP address that the applet was loaded from.

You can run a Java server on whatever port you want. Each server will accept incoming requests on one port.
The correct way is simply run on one port and each connection will instantiate a new servlet instance (which happens to run in its own thread) that can then service that request. You usually don't need to run separate ports or worry about concurrency, especially if all the stuff that's shared between connections (e.g. multiple players in one game) is handled through database read/writes.
Your host (GoDaddy) will have to allow you use of those ports, but if they are providing proper hosting (not virtual hosting) and given you your own IP there's no reason why you shouldn't be able to.

Your solution may work theoritically, and I like AlexR's solution. But providers like godaddy doesnt let you run a java server, on ANY port. You will need to find out somebody who does. What I found is the cost goes up from $5/mo to about $20/mo, but you get a much better (read faster) machine. Good wishes, - MS.

Secure Debugging for Production JVMs

We have some applications that sometimes get into a bad state, but only in production (of course!). While taking a heap dump can help to gather state information, it's often easier to use a remote debugger. Setting this up is easy -- one need only add this to his command line:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=PORT
There seems to be no available security mechanism, so turning on debugging in production would effectively allow arbitrary code execution (via hotswap).
We have a mix of 1.4.2 and 1.5 Sun JVMs running on Solaris 9 and Linux (Redhat Enterprise 4). How can we enable secure debugging? Any other ways to achieve our goal of production server inspection?
Update: For JDK 1.5+ JVMs, one can specify an interface and port to which the debugger should bind. So, KarlP's suggestion of binding to loopback and just using a SSH tunnel to a local developer box should work given SSH is set up properly on the servers.
However, it seems that JDK1.4x does not allow an interface to be specified for the debug port. So, we can either block access to the debug port somewhere in the network or do some system-specific blocking in the OS itself (IPChains as Jared suggested, etc.)?
Update #2: This is a hack that will let us limit our risk, even on 1.4.2 JVMs:
Command line params:
-Xdebug
-Xrunjdwp:
transport=dt_socket,
server=y,
suspend=n,
address=9001,
onthrow=com.whatever.TurnOnDebuggerException,
launch=nothing
Java Code to turn on debugger:
try {
throw new TurnOnDebuggerException();
} catch (TurnOnDebugger td) {
//Nothing
}
TurnOnDebuggerException can be any exception guaranteed not to be thrown anywhere else.
I tested this on a Windows box to prove that (1) the debugger port does not receive connections initially, and (2) throwing the TurnOnDebugger exception as shown above causes the debugger to come alive. The launch parameter was required (at least on JDK1.4.2), but a garbage value was handled gracefully by the JVM.
We're planning on making a small servlet that, behind appropriate security, can allow us to turn on the debugger. Of course, one can't turn it off afterward, and the debugger still listens promiscuously once its on. But, these are limitations we're willing to accept as debugging of a production system will always result in a restart afterward.
Update #3: I ended up writing three classes: (1) TurnOnDebuggerException, a plain 'ol Java exception, (2) DebuggerPoller, a background thread the checks for the existence of a specified file on the filesystem, and (3) DebuggerMainWrapper, a class that kicks off the polling thread and then reflectively calls the main method of another specified class.
This is how its used:
Replace your "main" class with DebuggerMainWrapper in your start-up scripts
Add two system (-D) params, one specifying the real main class, and the other specifying a file on the filesystem.
Configure the debugger on the command line with the onthrow=com.whatever.TurnOnDebuggerException part added
Add a jar with the three classes mentioned above to the classpath.
Now, when you start up your JVM everything is the same except that a background poller thread is started. Presuming that the file (ours is called TurnOnDebugger) doesn't initially exist, the poller checks for it every N seconds. When the poller first notices it, it throws and immediately catches the TurnOnDebuggerException. Then, the agent is kicked off.
You can't turn it back off, and the machine is not terribly secure when its on. On the upside, I don't think the debugger allows for multiple simultaneous connections, so maintaining a debugging connection is your best defense. We chose the file notification method because it allowed us to piggyback off of our existing Unix authen/author by specifying the trigger file in a directory where only the proper uses have rights. You could easily build a little war file that achieved the same purpose via a socket connection. Of course, since we can't turn off the debugger, we'll only use it to gather data before killing off a sick application. If anyone wants this code, please let me know. However, it will only take you a few minutes to throw it together yourself.

If you use SSH you can allow tunneling and tunnel a port to your local host. No development required, all done using sshd, ssh and/or putty.
The debug socket on your java server can be set up on the local interface 127.0.0.1.

You're absolutely right: the Java Debugging API is inherently insecure. You can, however, limit it to UNIX domain sockets, and write a proxy with SSL/SSH to let you have authenticated and encrypted external connections that are then proxied into the UNIX domain socket. That at least reduces your exposure to someone who can get a process into the server, or someone who can crack your SSL.

Export information/services into JMX and then use RMI+SSL to access it remotely. Your situation is what JMX is designed for (the M stands for Management).

Good question.
I'm not aware of any built-in ability to encrypt connections to the debugging port.
There may be a much better/easier solution, but I would do the following:
Put the production machine behind a firewall that blocks access to the debugging port(s).
Run a proxy process on the host itself that connects to the port, and encrypts the input and output from the socket.
Run a proxy client on the debugging workstation that also encrypts/decrypts the input. Have this connect to the server proxy. Communication between them would be encrypted.
Connect your debugger to the proxy client.