Missing features and design issues

Goal of the project

Obviously, Excubitor is far from a monitoring system that could be used in a production environment. However, this isn't the purpose of this project. Its purpose was and is to learn benefits and drawbacks of various technologies with a focus on flexibility and extensibility. This is the reason, the Excubitor modules are isolated the way they are.

What would a good monitoring system need?

While the implemented aspects, CPU, RAM, SWAP and Filesystem Usage, are in fact part of the feature set of a good monitoring software, Excubitor lacks mission-critical features such as analyzing logs and running services. Also, it does not provide any functionality to monitor network parameters nor the number of requests towards the monitored system.

However, due to the modular nature of Excubitor this would be easy to implement - or would it? Due to the approach we chose in loading and ticking modules, we do not provide any possibility for the user to interact with the modules directly. So, the only way to modify incoming data is through the backend (as seen in HIST requests) or through the frontend (as seen in the diagrams rendered in some components).

Things like analyzing logs would be possible. But we would need to follow the protocol guidelines of Excubitor pretty closely. With each message returned by a module on a tick, we would have to send exactly one log entry, so that they could be retrieved through a HIST request and would not defeat the purpose of a history. Besides that any filtering would need to happen in the frontend which can be very unresponsive. A solution for this could be to provide a method to manipulate the json data on the backend - which would add an overhead to retrieving data.

Monitoring running services would be harder though. While, theoretically, one could send a list of all services and their status to the backend, this would induce a heavy overhead in performance and disk usage. The other option to only send updates of service status to the backend would make the frontend responsible for calculating the current state which would not be feasible at all.

This shows, that the design we chose is not suitable for an all-round monitoring system and is focused on live data that changes frequently - or frequently enough so that saving it regularly would actually make sense.

Security issues

Loading untrusted components

The principle of connecting to an unknown backend and loading frontend components for display in the user's browser is a pretty bad idea as the user has no way to know whether it is communicating with whom he thinks to communicate with.

Sending credentials to an untrusted target

Also, the user's credentials are transmitted with every authentication request - which is sent to a user given target. If the user mistypes or does not know the server on the other side, their credentials are sent to a potential attacker. In this case not even TLS would provide sufficient security because a mistyped domain can be secured using a certificated provided by a trusted certificate authority never the less. A way to mitigate this issue would be to use key-based authentication and/or provide a server identity like SSH does.

Running untrusted modules with root privileges

Another security issue lies on the server side where modules are loaded into the application with root privileges. However, the application only needs root privileges for certain tasks such as authenticating with the system through PAM. This need could be avoided through using an LDAP server (or a similar solution) through PAM for authentication as this way, PAM wouldn't have to read from the protected /etc/shadow. However, it would be easier to start the modules using another user account especially for the Excubitor application. This can be done through adding a SysProcAttr struct with the user's UID and GID set to the command executing the module. This however, still requires the main application to run with root privileges.