This content has been marked as final. Show 7 replies
Your question doesn't make sense. Any instance of the Java VM already is a 'task' in the Task Manager sense, and a 'program' in the sense of Windows Firewall.
Well, it does make sense, if you think about it.
Having 2 Java Programms, a Firewall can not distinguish between them, it can not "see" which java programm is currently running. Thereby it may grant access to the network to an application I dont want to have access to it.
Same for process managing.
You could make copies of javaw.exe with different names and use those to differentiate your applications which should be treated differently by the firewall.
Actually, you comments aren't necessarily unclear. They are more incomplete. You didn't really provide too much details as to what you are trying to do or experiencing. Genrally speaking, most firewalls will allow you to not only monitor and block/permit by application executible name, but also by the port used to make the exchange, the content type, and numerous other attributes. So if you have multiple java applications, but want to allow or restrict one in particular, simply block by a specific port or set of ports or one of the other attributes supported by your particular firewall.
As a simply example, take a look at the Windows Firewall for XP. Notice that you can define the app, the port, and protocol
Thank you for your ideas. Both "solutions" areworkarounds. for example, many tools will aceess Port 80, so the filter-by-port-solution will not work. On the other hand this is about a security-concern, so most propably a "evil" software would use port 80 to communicate
The idea of different javaw.exe may work (I did not test wether I need to copy or rename other files), but many java-tools are started using a corresponding.exe (which starts the vm with corresponding parameters - since I do not know them, it's hard to workaround this issue)
any other ideas?
Any other ideas besides the ones you've already been given that you haven't tried yet?
You're getting free advice here. Don't count on it continuing forever.
927589 wrote:Those applications should then be reconfigured to use another port. No tool will just use port 80 (or any other port below 1000) without giving a choice to change it, there is too much risk of conflict. You're not going to solve this with near-zero effort, it is going to take plenty of investigation, preparation, planning and documenting to be able to properly create an environment in which you can do what you want and maintain it.
Thank you for your ideas. Both "solutions" areworkarounds. for example, many tools will aceess Port 80, so the filter-by-port-solution will not work.