RHQ has great features in the area of resource management and we are interested especially in JBoss side.
While setting up and using an RHQ installation in our company we came to the idea that these features could introduce security issues. For example an attacker could take control over the RHQ server as "rhqadmin" and could deploy his malicious code in all monitored JBosses and cause fatal damages.
Also there is the posibility to start and stop the server and to deploy and run scripts, giving the attacker full control on the monitored platform.
Another example is for JMS queues, RHQ gives the possibility to remove all mesages in a queue, which is obviously a very sensitive operation.
Could it be the case to make features like "content", "bundles", "connection settings", "operations" have the possibility to be disabled ? Some people may choose to focus on the Monitoring part of the tool.
Vlad Craciunoiu - 1&1 Internet AG
> "An attacker could take control over the RHQ server as "rhqadmin"
Just as with any system requiring login credentials, RHQ assumes administrators will safeguard systems and passwords to avoid such intrusion. This is the same issue with Linux and its "root" password or any "superuser" password.
That said, you can submit an RFE to bugzilla to request the ability to disable certain subsystems like the Bundle and Operation subsystem. However, you won't be able to simply disable some things like "Connection Settings" because that is how you tell RHQ how all its plugin components connect to their resources (e.g. its how you tell the jboss pugin what the JMX credentials are to connect to a monitored JBossAS app server). So that is required for the system to even work.
RHQ also allows you to create additional users that have limited privileges. For example, you could create a user bob that only has view access to a certain set of Resources and no access to the bundle subsystem. For details on the RHQ authorization system, see http://rhq-project.org/display/JOPR2/Security+Model.
Note, the default password for the rhqadmin user is "rhqadmin". Obviously, if you're concerned about security, one of the first things you should do is change that password. This can be done via the RHQ GUI (go to the Administration>Users page).
OK, what about if an attacker breaks into the RHQ server machine and logs-in as an operating system user.
He can build and run his own application (an RHQ-agent "client") which connects to the RHQ agents and call their remote interface, just like the RHQ server does. He can obtain the agents security tokens or SSL certificates and also can access the RHQ database.
In a big enterprise environment the RHQ server can be a point of weakness which can give access to all monitored machines. This is why we think it's useful to have a "read-only", "monitoring" agent (the possibility to disable the "write" parts of the agent's interface).
I think that is a very good idea and wouldn't even be too hard to implement, imho. As you say this would prevent anyone (be it the RHQ server or an attacker) from using the agent to do any changes on the agent machine. It could e a configuration switch that could be flipped only by re-reading the agent configuration file, for example - which would make it unchangeable by any other means than by having an access to the agent machine and having the ability to restart the agent process from the commandline.
Vlad, could you please create a BZ with a feature request for this, so that we can think about incorporating the feature in some future version of RHQ? We'd also very much appreciate any help / code you could provide to help us get this into RHQ faster.
You can enter the BZ in here https://bugzilla.redhat.com/enter_bug.cgi?product=RHQ%20Project and prepend the BZ title with "RFE" or you can add the Keyword "FutureFeature" (not sure if you are going to have access to that field).
We discovered a security problem: when login to RHQ GUI the user & password are sent in clear text from browser to RHQ server.
An attacker could snoop one's [general purpose/works for everything :)] password from the network with tcpdump, below is an example.
This is something that should not be.
What can we do about this ?
No. Time Source Destination Protocol Length Info
83343 458.446186000 172.28.125.37 172.28.124.63 HTTP 636 POST /j_security_check.do HTTP/1.1 (application/x-www-form-urlencoded)
Hypertext Transfer Protocol
POST /j_security_check.do HTTP/1.1\r\n
[Expert Info (Chat/Sequence): POST /j_security_check.do HTTP/1.1\r\n]
Request Method: POST
Request URI: /j_security_check.do
Request Version: HTTP/1.1
[Full request URI: http://yyy:7080/j_security_check.do]
[HTTP request 1/1]
[Response in frame: 83362]
Line-based text data: application/x-www-form-urlencoded