BBwin Security role?
list Mario Andre
Hi guys, I was looking at the bbwin command line tool bbwincmd.exe help page and something really get me worried. There we have : *Sending a drop bbwincmd.exe <bbdisplay>[:<port>] drop <hostname> [<testname>] Sending a hostname rename bbwincmd.exe <bbdisplay>[:<port>] rename <hostname> <newhostname> Sending a test rename bbwincmd.exe <bbdisplay>[:<port>] rename <hostname> <oldtestname> <newtestname Sending a download message. default download path is the filename requested it bbwincmd.exe <bbdisplay>[:<port>] download <hostname> <filename> [<path>] *I've tried from an agent to drop a test and thanks God doesn't work. I've tried from a linux xymon-client and thanks God again didin't work too. I don't know why this is in the documentation , but my question is why this kind of administration commands are available at the agents? In my opinion this is not a good idea. If one day this kind of thing work, how we can avoid the server to execute this? Is there something in the configuration? Regards, Mario.
list dOCtoR MADneSs
On Wed, 28 Apr 2010 11:23:06 -0300, Mario Andre Panza
▸
<user-82c7780661a4@xymon.invalid> wrote:Hi guys, I was looking at the bbwin command line tool bbwincmd.exe help page and something really get me worried. There we have : *Sending a drop bbwincmd.exe <bbdisplay>[:<port>] drop <hostname> [<testname>] Sending a hostname rename bbwincmd.exe <bbdisplay>[:<port>] rename <hostname> <newhostname> Sending a test rename bbwincmd.exe <bbdisplay>[:<port>] rename <hostname> <oldtestname> <newtestname Sending a download message. default download path is the filename requested it bbwincmd.exe <bbdisplay>[:<port>] download <hostname> <filename>
[<path>]
*I've tried from an agent to drop a test and thanks God doesn't work.
I've
tried from a linux xymon-client and thanks God again didin't work too. I don't know why this is in the documentation , but my question is why this kind of administration commands are available at the agents? In my opinion this is not a good idea. If one day this kind of thing work, how we can avoid the server to execute this? Is there something in the configuration? Regards, Mario.
Hi, I never tried to drop data from bbwin, but from bb command on Linux, I can do it. The only way I found to block it, until a new Xymon version including auth is released, is to use firewall rules to filter hosts allowed to contact Xymon server on port 1984 (default one)
list David Baldwin
▸
Mario Andre Panza wrote:
Hi guys, I was looking at the bbwin command line tool bbwincmd.exe help page and something really get me worried. There we have : /Sending a drop bbwincmd.exe <bbdisplay>[:<port>] drop <hostname> [<testname>] Sending a hostname rename bbwincmd.exe <bbdisplay>[:<port>] rename <hostname> <newhostname> Sending a test rename bbwincmd.exe <bbdisplay>[:<port>] rename <hostname> <oldtestname> <newtestname Sending a download message. default download path is the filename requested it bbwincmd.exe <bbdisplay>[:<port>] download <hostname> <filename> [<path>] /I've tried from an agent to drop a test and thanks God doesn't work. I've tried from a linux xymon-client and thanks God again didin't work too. I don't know why this is in the documentation , but my question is why this kind of administration commands are available at the agents? In my opinion this is not a good idea. If one day this kind of thing work, how we can avoid the server to execute this? Is there something in the configuration?
There are a number of arguments to hobbitd which are specified in
/etc/hobbit/hobbitlaunch.cfg in [hobbitd] section. The relevant defaults
are '--admin-senders=127.0.0.1,$BBSERVERIP' which block access to the
/drop/ and /rename/ commands from other than the server. Not sure about
/download/.
From 'man hobbitd'
--status-senders=IP[/MASK][,IP/MASK]
Controls which hosts may send "status", "combo", "config" and
"query" commands to hobbitd.
By default, any host can send status-updates. If this option is
used, then status-updates are accepted only if they are sent by one of
the IP-adresses listed here, or if they are sent from the IP-address of
the host that the updates pertains to (this is to allow Xymon clients to
send in their own status updates, without having to list all clients
here). So typically you will need to list your BBNET servers here.
The format of this option is a list of IP-adresses, optionally with
a network mask in the form of the number of bits. E.g. if you want to
accept status-updates from the host 172.16.10.2, you would use
--status-senders=172.16.10.2
whereas if you want to accept status updates from both 172.16.10.2
and from all of the hosts on the 10.0.2.* network (a 24-bit IP network),
you would use
--status-senders=172.16.10.2,10.0.2.0/24
--maint-senders=IP[/MASK][,IP/MASK]
Controls which hosts may send maintenance commands to hobbitd.
Maintenance commands are the "enable", "disable", "ack" and "notes"
commands. Format of this option is as for the --status-senders option.
It is strongly recommended that you use this to restrict access to these
commands, so that monitoring of a host cannot be disabled by a rogue
user - e.g. to hide a system compromise from the monitoring system.
Note: If messages are sent through a proxy, the IP-address
restrictions are of little use, since the messages will appear to
originate from the proxy server address. It is therefore strongly
recommended that you do NOT include the address of a server running
bbproxy in the list of allowed addresses.
--www-senders=IP[/MASK][,IP/MASK]
Controls which hosts may send commands to retrieve the state of
hobbitd. These are the "hobbitdlog", "hobbitdboard" and "hobbitdxboard"
commands, which are used by bbgen(1) and bbcombotest(1) to retrieve the
state of the Xymon system so they can generate the Xymon webpages.
Note: If messages are sent through a proxy, the IP-address
restrictions are of little use, since the messages will appear to
originate from the proxy server address. It is therefore strongly
recommended that you do NOT include the address of a server running
bbproxy in the list of allowed addresses.
--admin-senders=IP[/MASK][,IP/MASK]
Controls which hosts may send administrative commands to hobbitd.
These commands are the "drop" and "rename" commands. Access to these
should be restricted, since they provide an un-authenticated means of
completely disabling monitoring of a host, and can be used to remove all
traces of e.g. a system compromise from the Xymon monitor.
Note: If messages are sent through a proxy, the IP-address
restrictions are of little use, since the messages will appear to
originate from the proxy server address. It is therefore strongly
recommended that you do NOT include the address of a server running
bbproxy in the list of allowed addresses.
--
David Baldwin - IT Unit
Australian Sports Commission www.ausport.gov.au
Tel 02 62147830 Fax 02 62141830 PO Box 176 Belconnen ACT 2616
user-cbbf693f2c89@xymon.invalid Leverrier Street Bruce ACT 2617
Keep up to date with what's happening in Australian sport visit http://www.ausport.gov.au
This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender.
list Mario Andre
Thanks David! That's the point --admin-senders ! Xymon is the best! Regards, Mario. On Wed, Apr 28, 2010 at 11:20 PM, David Baldwin <
▸
user-cbbf693f2c89@xymon.invalid> wrote:
Mario Andre Panza wrote: Hi guys, I was looking at the bbwin command line tool bbwincmd.exe help page and something really get me worried. There we have : *Sending a drop bbwincmd.exe <bbdisplay>[:<port>] drop <hostname> [<testname>] Sending a hostname rename bbwincmd.exe <bbdisplay>[:<port>] rename <hostname> <newhostname> Sending a test rename bbwincmd.exe <bbdisplay>[:<port>] rename <hostname> <oldtestname> <newtestname Sending a download message. default download path is the filename requested it bbwincmd.exe <bbdisplay>[:<port>] download <hostname> <filename> [<path>] *I've tried from an agent to drop a test and thanks God doesn't work. I've tried from a linux xymon-client and thanks God again didin't work too. I don't know why this is in the documentation , but my question is why this kind of administration commands are available at the agents? In my opinion this is not a good idea. If one day this kind of thing work, how we can avoid the server to execute this? Is there something in the configuration? There are a number of arguments to hobbitd which are specified in /etc/hobbit/hobbitlaunch.cfg in [hobbitd] section. The relevant defaults are
'--admin-senders=127.0.0.1,$BBSERVERIP' which block access to the *drop*and
▸
*rename* commands from other than the server. Not sure about *download*.
From 'man hobbitd'
--status-senders=IP[/MASK][,IP/MASK]
Controls which hosts may send "status", "combo", "config" and "query"
commands to hobbitd.
By default, any host can send status-updates. If this option is used,
then status-updates are accepted only if they are sent by one of the
IP-adresses listed here, or if they are sent from the IP-address of the host
that the updates pertains to (this is to allow Xymon clients to send in
their own status updates, without having to list all clients here). So
typically you will need to list your BBNET servers here.
The format of this option is a list of IP-adresses, optionally with a
network mask in the form of the number of bits. E.g. if you want to accept
status-updates from the host 172.16.10.2, you would use
--status-senders=172.16.10.2
whereas if you want to accept status updates from both 172.16.10.2 and
from all of the hosts on the 10.0.2.* network (a 24-bit IP network), you
would use
--status-senders=172.16.10.2,10.0.2.0/24
--maint-senders=IP[/MASK][,IP/MASK]
Controls which hosts may send maintenance commands to hobbitd.
Maintenance commands are the "enable", "disable", "ack" and "notes"
commands. Format of this option is as for the --status-senders option. It is
strongly recommended that you use this to restrict access to these commands,
so that monitoring of a host cannot be disabled by a rogue user - e.g. to
hide a system compromise from the monitoring system.
Note: If messages are sent through a proxy, the IP-address restrictions
are of little use, since the messages will appear to originate from the
proxy server address. It is therefore strongly recommended that you do NOT
include the address of a server running bbproxy in the list of allowed
addresses.
--www-senders=IP[/MASK][,IP/MASK]
Controls which hosts may send commands to retrieve the state of
hobbitd. These are the "hobbitdlog", "hobbitdboard" and "hobbitdxboard"
commands, which are used by bbgen(1) and bbcombotest(1) to retrieve the
state of the Xymon system so they can generate the Xymon webpages.
Note: If messages are sent through a proxy, the IP-address restrictions
are of little use, since the messages will appear to originate from the
proxy server address. It is therefore strongly recommended that you do NOT
include the address of a server running bbproxy in the list of allowed
addresses.
--admin-senders=IP[/MASK][,IP/MASK]
Controls which hosts may send administrative commands to hobbitd. These
commands are the "drop" and "rename" commands. Access to these should be
restricted, since they provide an un-authenticated means of completely
disabling monitoring of a host, and can be used to remove all traces of e.g.
a system compromise from the Xymon monitor.
Note: If messages are sent through a proxy, the IP-address restrictions
are of little use, since the messages will appear to originate from the
proxy server address. It is therefore strongly recommended that you do NOT
include the address of a server running bbproxy in the list of allowed
addresses.
--
David Baldwin - IT Unit
Australian Sports Commission www.ausport.gov.au
Tel 02 62147830 Fax 02 62141830 PO Box 176 Belconnen ACT user-0e3dcac72dc1@xymon.invalid Leverrier Street Bruce ACT 2617
Keep up to date with what's happening in Australian sport visit
www.ausport.gov.au
▸
This message is intended for the addressee named and may contain
confidential and privileged information. If you are not the intended
recipient please note that any form of distribution, copying or use of this
communication or the information in it is strictly prohibited and may be
unlawful. If you receive this message in error, please delete it and notify
the sender.