Hi there,
This is my first Hobbit install, I am still fumbling around on lots of things. Great software, after installing it I wonder how I survived without it.
I have 3 totally distinct questions.
I am running as many daemons as possible on 127.0.0.1 in case I make a mistake in my iptables rules and as a general security rule anyway. I added a 127.0.0.1 localhost line in etc/bb-hosts to monitor them. Is this the correct/preferred way to do it or can I monitor them on a single line with the public ip of the host ?
I configured clamd so that it uses /tmp/clamd for communications. Can I still monitor it with Hobbit ? I can't check the process (see question 3). I tried /tmp/clamd as a port in bb-services and saw an atoi() must be called on it ;-)
The reason I am using a local socket is that clamassassin looks for it to know whether to call the clamscan binary on each and every mail or to use clamdscan daemon. I could force it to use the daemon, but I don't know if it'll still call the binary in cas the daemon is down.
- Not directly Hobbit related but might need a turnaround.
My kernel is patched with -grsec, which implies only root can access /proc
or see other user's processes in a "ps" command. The result is that the
hobbit-client log is filled with "access denied" on /proc/net/snmp (which
I don't really mind) but also that the stats about users and especially
number of processes is totally and utterly wrong, and I'd need this
information (I have some random load peaks to diagnose). Do I need to run
parts of hobbit as root ? Which ones ? What's the risk involved ?
Or are there other solutions ? (the grsec documentation is non-existant or
very well hidden).
I might have some further questions about mysql monitoring, but http://www.hswn.dk/hobbiton/2006/06/msg00016.html looks promising, so I'll give it a try.
Thanks in advance for any help. Sincerely, JG
John GALLET a écrit :
My kernel is patched with -grsec, which implies only root can access /proc or see other user's processes in a "ps" command.
You can try running the commands in client/bin/hobbitclient-linux.sh with sudo.
in /etc/sudoers, put :
hobbituser ALL=(root) NOPASSWD: /bin/ps
and in client/bin/hobbitclient-linux.sh, replace
< ps -Aw -o pid,ppid,user,start,state,pri,pcpu,time,pmem,rsz,vsz,cmd
sudo ps -Aw -o pid,ppid,user,start,state,pri,pcpu,time,pmem,rsz,vsz,cmd
-- Charles Goyard - cgoyard at cvf.fr - (+33) 1 45 38 01 31
On Thu, Aug 17, 2006 at 10:56:48AM +0200, John GALLET wrote:
- I am running as many daemons as possible on 127.0.0.1 in case I make a mistake in my iptables rules and as a general security rule anyway. I added a 127.0.0.1 localhost line in etc/bb-hosts to monitor them. Is this the correct/preferred way to do it or can I monitor them on a single line with the public ip of the host ?
If you want to make sure that the ONLY run on 127.0.0.1, I'd setup two sets of tests: One with the public IP, and one with 127.0.0.1. Then you can check the same services on both, with one of them being a "negative" test (i.e. something which must NOT be available). Eg. if smtp should only be listening locally:
127.0.0.1 myserver-local # testip smtp 12.34.56.78 myserver-public # testip !smtp
The "testip" makes Hobbit use the IP-address from the bb-hosts file, instead of trying to determine the IP from the hostname.
- I configured clamd so that it uses /tmp/clamd for communications. Can I still monitor it with Hobbit ? I can't check the process (see question 3). I tried /tmp/clamd as a port in bb-services and saw an atoi() must be called on it ;-)
"clamd" and the other tests in bb-services only work for network tests, so - no, Hobbit cannot monitor a service communicating via a local unix socket.
- Not directly Hobbit related but might need a turnaround.
My kernel is patched with -grsec, which implies only root can access /proc or see other user's processes in a "ps" command. The result is that the hobbit-client log is filled with "access denied" on /proc/net/snmp (which I don't really mind) but also that the stats about users and especially number of processes is totally and utterly wrong, and I'd need this information (I have some random load peaks to diagnose). Do I need to run parts of hobbit as root ? Which ones ? What's the risk involved ?
As Charles writes, you can use "sudo" to permit the hobbit user to run the privileged commands with root privs. The risk in doing that obviously is that if a user manages to break into your box and get shell access as the "hobbit" user, then he can run those same commands with root privileges.
Regards, Henrik
Thanks to both of you for the answers.
I'll run clamd as a port socket daemon and try to check/tweak clamassassin to fall back on the standalone binary if need be.
As Charles writes, you can use "sudo" to permit the hobbit user to run the privileged commands with root privs. The risk in doing that obviously is that if a user manages to break into your box and get shell access as the "hobbit" user, then he can run those same commands with root privileges.
When it comes to security, a lot of things don't seem "obvious" to me ! The risk assesment of "how bad it can get" is in general not too hard to determine, but the risk level is not (IMHO).
Especially the part about breaking into my box with the hobbit user. It's not named "hobbit", neither is its group. I use iptable and only allow INPUT on 1984 from my boxes, I htpassword protect all the hobbit cgi directories and run them as "nobody/nobody" and the shell account passwd is strong. But I can very easily have forgotten some *basic* security measure that applies to Hobbit (and which I am not familiar with because I don't run such daemons in general).
Sincerely, JG
On Thu, Aug 17, 2006 at 01:57:05PM +0200, John GALLET wrote:
As Charles writes, you can use "sudo" to permit the hobbit user to run the privileged commands with root privs. The risk in doing that obviously is that if a user manages to break into your box and get shell access as the "hobbit" user, then he can run those same commands with root privileges.
When it comes to security, a lot of things don't seem "obvious" to me !
Well, security often is far from obvious. If it were, we wouldn't have all those security incidents with computers.
Especially the part about breaking into my box with the hobbit user. It's not named "hobbit", neither is its group. I use iptable and only allow INPUT on 1984 from my boxes, I htpassword protect all the hobbit cgi directories and run them as "nobody/nobody" and the shell account passwd is strong. But I can very easily have forgotten some *basic* security measure that applies to Hobbit (and which I am not familiar with because I don't run such daemons in general).
Securing Hobbit isn't very different from securing any kind of network service, and it sounds like you have it pretty much nailed down.
Hobbit in itself doesn't provide a whole lot of security settings; so far I have been quite happy to have security handled outside Hobbit by firewalls, Apache htaccess checks and general unix permissions. There is one security feature that you might want to look into: hobbitd (the core daemon) has a series of options controlling which IP-adresses it will accept certain commands from. The "--admin-senders" option especially controls who may ask the Hobbit server to delete or rename hosts being monitored; if you're going to attack a server, it sure is nice if you can delete it from the monitoring system first - so that should be locked down. The default setting in hobbitlaunch.cfg only allows these commands to come from the Hobbit server itself.
A related option - the --maint-senders option - controls who can send commands to disable monitoring of a host. This is NOT restricted by default; if you only enable/disable hosts and tests via the built-in Hobbit web-utilities, then you can restrict this also to only accept such commands from the Hobbit server itself.
Finally, the "--status-senders" option controls who may update the status of a test. This is not turned on by default, so anyone can send in a status update for any host/service that Hobbit monitors. If you enable this, then only the host itself is allowed to send updates; the Hobbit server itself and any other servers running network tests must be allowed to send status updates.
All of these are described in the hobbitd(8) man-page.
Regards, Henrik
On Thursday 17 August 2006 10:56, John GALLET wrote:
Hi there,
This is my first Hobbit install, I am still fumbling around on lots of things. Great software, after installing it I wonder how I survived without it.
I have 3 totally distinct questions.
I am running as many daemons as possible on 127.0.0.1 in case I make a mistake in my iptables rules and as a general security rule anyway. I added a 127.0.0.1 localhost line in etc/bb-hosts to monitor them. Is this the correct/preferred way to do it or can I monitor them on a single line with the public ip of the host ?
I configured clamd so that it uses /tmp/clamd for communications. Can I still monitor it with Hobbit ? I can't check the process (see question 3). I tried /tmp/clamd as a port in bb-services and saw an atoi() must be called on it ;-)
The reason I am using a local socket is that clamassassin looks for it to know whether to call the clamscan binary on each and every mail or to use clamdscan daemon. I could force it to use the daemon, but I don't know if it'll still call the binary in cas the daemon is down.
Just compile clamassassin with --enable-clamdscan, looking for a specific named socket to determine the availability of a a service which can run on either a port or a socket is quite weird ...
- Not directly Hobbit related but might need a turnaround.
My kernel is patched with -grsec, which implies only root can access /proc or see other user's processes in a "ps" command. The result is that the hobbit-client log is filled with "access denied" on /proc/net/snmp (which I don't really mind) but also that the stats about users and especially number of processes is totally and utterly wrong, and I'd need this information (I have some random load peaks to diagnose). Do I need to run parts of hobbit as root ? Which ones ? What's the risk involved ? Or are there other solutions ? (the grsec documentation is non-existant or very well hidden).
Seems you should be able to allow a specific user to get a full process listing via gradm ...
Regards, Buchan
-- Buchan Milne ISP Systems Specialist B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)
participants (4)
-
bgmilne＠staff.telkomsa.net
-
cgoyard＠cvf.fr
-
henrik＠hswn.dk
-
john.gallet＠wanadoo.fr