- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can't seem to lock down the remote agent in any way. It seems that it listens on port 5000 and accepts any connection from anyone, anyplace and will send them any file the user running the process can read.
Umm, that seems kind of bad to me.
Is there some way to lock it down by password? Yes, we can use iptables to lock down packets, but that's fairly ugly.
Umm, that seems kind of bad to me.
Is there some way to lock it down by password? Yes, we can use iptables to lock down packets, but that's fairly ugly.
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi David,
I think that there is a way to change the port. Perhaps your best bet is to use something like hosts.allow or hosts.deny to only give certain systems access to this port.
Alternatively, you can use the native Linux product, a command-line product, to collect data directly on the Linux system. Then, if you want to view it on a Windows system, you can pack it on the Linux system and unpack it on the Windows system. This way, there is no need to have the remote Agent running on Linux at all. But, if you want to view the data on Windows, this approach may be a bit inconvenient (although, with the proper scripts, you may be able to reduce the inconvenience).
Aaron Levinson
I think that there is a way to change the port. Perhaps your best bet is to use something like hosts.allow or hosts.deny to only give certain systems access to this port.
Alternatively, you can use the native Linux product, a command-line product, to collect data directly on the Linux system. Then, if you want to view it on a Windows system, you can pack it on the Linux system and unpack it on the Windows system. This way, there is no need to have the remote Agent running on Linux at all. But, if you want to view the data on Windows, this approach may be a bit inconvenient (although, with the proper scripts, you may be able to reduce the inconvenience).
Aaron Levinson
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Guys,
The port that the Linux remote agent uses (port 50000, btw) is hardwired in. No way to change it currently. FYI only.
cheers
jdg
The port that the Linux remote agent uses (port 50000, btw) is hardwired in. No way to change it currently. FYI only.
cheers
jdg
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Changing the port wouldn't really help all that much anyway. An insecure protocol doesn't become more secure by changing its port, except perhaps the extra effort of figuring out the protocol.
And adjusting the hosts.allow/hosts.deny files won't help, since the VTune client doesn't check them.
This should be considered a defect in the VTune client. It makes the client almost unusable for the way I wanted to use it. (Run it on several servers, if a performance problem is reported on a server, then connect to that server's analyzer and take a look.)
At least a list of permitted IPs is really needed.
DS
And adjusting the hosts.allow/hosts.deny files won't help, since the VTune client doesn't check them.
This should be considered a defect in the VTune client. It makes the client almost unusable for the way I wanted to use it. (Run it on several servers, if a performance problem is reported on a server, then connect to that server's analyzer and take a look.)
At least a list of permitted IPs is really needed.
DS
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
You're absolutely correct. I'm not sure what I was thinking when it comes to hosts.allow and hosts.deny.
Until a change is made to the remote agent for Linux, it seems that your best bet is to use ipchains (or some other firewall software) to block this port except for certain IP addresses.
To encourage the security issue to be fixed, you can submit a bug report via Intel Premier Support. Go to http://support.intel.com/support/performancetools/support.htm for more information. In the report, if you can supply sample code or describe the sort of things someone could do to compromise a system via the Remote Agent, that will quite possibly accelerate the issue. Also, if you could describe the ease at which you were able to figure out the protocol (plain-text, etc.), that would be helpful.
AaronL
You're absolutely correct. I'm not sure what I was thinking when it comes to hosts.allow and hosts.deny.
Until a change is made to the remote agent for Linux, it seems that your best bet is to use ipchains (or some other firewall software) to block this port except for certain IP addresses.
To encourage the security issue to be fixed, you can submit a bug report via Intel Premier Support. Go to http://support.intel.com/support/performancetools/support.htm for more information. In the report, if you can supply sample code or describe the sort of things someone could do to compromise a system via the Remote Agent, that will quite possibly accelerate the issue. Also, if you could describe the ease at which you were able to figure out the protocol (plain-text, etc.), that would be helpful.
AaronL
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page