I've got some servers out in the DMZ that can't talk directly to the corporate network. I can get out to them via socks/ssh. I do not want to run another listening service (msgcache) out there in the DMZ. Is there a way to configure the client to collect messages to a file (without msgcache listening), and then go retrieve/process those file(s) via ssh from the Hobbit server and process normally?
What I'm doing now is not installing the client in the DMZ, and instead using a custom Hobbit server script that socks/ssh'es out to the DMZ and runs it's own data collection commands. The data collected is similar to what the client would normally do, but it's all done via custom script without any help from the Hobbit client.
I guess what I'm looking for is a hobbitfetch variant that uses ssh/scp rather than connecting to a msgcache listener. And along with that, a way to configure the client to collect data normally, but skip starting a listening service.
On Sat, June 2, 2007 22:50, Haertig, David F (Dave) wrote:
I guess what I'm looking for is a hobbitfetch variant that uses ssh/scp rather than connecting to a msgcache listener. And along with that, a way to configure the client to collect data normally, but skip starting a listening service.
Why not just use msgcache bound to a localhost address and ssh port tunneling, front-ended by autossh for persistence?
AUTOSSH_GATETIME=0
autossh -M 0 -f -f -N -L 127.0.0.2:1984:127.0.0.2:1984
-i <path-to-rsa-private-key> someunprivilegeduser at dmzserver.example.com
Install autossh. Do your key exchange, test ssh PKI authentication. Set msgcache to --listen=127.0.0.2 and --server=127.0.0.1, use "dmzserver.example.com 127.0.0.2 # testip pulldata" in bb-hosts, and you should be good to go, with a msgcache that cannot be fetched except via your tunnel. Note that the conn check for this bb-host entry will be meaningless, and you'll need to add -L port mappings for any other server-side tests you want.
Writing this from memory, so there might be a syntax error or misspelled option. But it's pretty close. You do need a very up-to-date ssh to specify the near-side IP on the -L port forward (which helps you to keep up with tunnels for different hosts--otherwise you have to use different ports; I actually put in /etc/hosts entries for the 127.0.0.x entries so I can call them by name). I know that the near-side ip spec is supported in the current repo versions for FC5 and up, RHEL5, and Centos5, but not in RHEL4 and down. Hope this helps.
Thanks. I'm familiar with ssh tunnels, pubkey authentication, ssh agents, etc. I use that quite a bit in other applications.
The issue I'm faced with is starting up a new listener out there in the DMZ. Any listener(even one only listening on the local adapter). That brings other people into this, with the associated reviews, paperwork, and so on. Reviews that I 100% agree with - putting on my security hat. I have a working and approved solution now using only socks/ssh and my custom scripts (from back in the Big Brother days when I first wrote this). I'm just investigating if it's possible to pull the formal Hobbit client into my existing solution methodology. Adding a listener is not a total deal breaker, I could probably gain the required approvals, but the overhead in getting that paperwork and approval done has me researching other possibilities.
Thanks for your detailed reply. Your solution is very much what I would have recommended to others in similar circumstances. I know from experience that it can be done simply and relatively securely. I think ssh is my favorite application. You can do so much with it. Tunneling, dynamic port forwarding, sshfs (a really cool technique to mount remote computers as local filesystems, with no server software required other than an ssh server).
-----Original Message----- From: Hobbit User [mailto:hobbit at epperson.homelinux.net] Sent: Sunday, June 03, 2007 8:34 AM To: hobbit at hswn.dk Subject: Re: [hobbit] Alternate to msgcache/hobbitfetch?
On Sat, June 2, 2007 22:50, Haertig, David F (Dave) wrote:
I guess what I'm looking for is a hobbitfetch variant that uses ssh/scp rather than connecting to a msgcache listener. And along with
that, a way to configure the client to collect data normally, but skip
starting a listening service.
Why not just use msgcache bound to a localhost address and ssh port tunneling, front-ended by autossh for persistence?
AUTOSSH_GATETIME=0 autossh -M 0 -f -f -N -L 127.0.0.2:1984:127.0.0.2:1984 \ -i <path-to-rsa-private-key> someunprivilegeduser at dmzserver.example.com
Install autossh. Do your key exchange, test ssh PKI authentication. Set msgcache to --listen=127.0.0.2 and --server=127.0.0.1, use "dmzserver.example.com 127.0.0.2 # testip pulldata" in bb-hosts, and you should be good to go, with a msgcache that cannot be fetched except via your tunnel. Note that the conn check for this bb-host entry will be meaningless, and you'll need to add -L port mappings for any other server-side tests you want.
Writing this from memory, so there might be a syntax error or misspelled option. But it's pretty close. You do need a very up-to-date ssh to specify the near-side IP on the -L port forward (which helps you to keep up with tunnels for different hosts--otherwise you have to use different ports; I actually put in /etc/hosts entries for the 127.0.0.x entries so I can call them by name). I know that the near-side ip spec is supported in the current repo versions for FC5 and up, RHEL5, and Centos5, but not in RHEL4 and down. Hope this helps.
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
Haertig, David F (Dave) wrote:
I've got some servers out in the DMZ that can't talk directly to the corporate network. I can get out to them via socks/ssh. I do not want to run another listening service (msgcache) out there in the DMZ. Is there a way to configure the client to collect messages to a file (without msgcache listening), and then go retrieve/process those file(s) via ssh from the Hobbit server and process normally?
What I'm doing now is not installing the client in the DMZ, and instead using a custom Hobbit server script that socks/ssh'es out to the DMZ and runs it's own data collection commands. The data collected is similar to what the client would normally do, but it's all done via custom script without any help from the Hobbit client.
I guess what I'm looking for is a hobbitfetch variant that uses ssh/scp rather than connecting to a msgcache listener. And along with that, a way to configure the client to collect data normally, but skip starting a listening service.
I can't remember where I saw it but I thought this functionality was already part of hobbit...
=G=
Haertig, David F (Dave) a écrit :
I've got some servers out in the DMZ that can't talk directly to the corporate network. I can get out to them via socks/ssh. I do not want to run another listening service (msgcache) out there in the DMZ. Is there a way to configure the client to collect messages to a file (without msgcache listening), and then go retrieve/process those file(s) via ssh from the Hobbit server and process normally?
What I'm doing now is not installing the client in the DMZ, and instead using a custom Hobbit server script that socks/ssh'es out to the DMZ and runs it's own data collection commands. The data collected is similar to what the client would normally do, but it's all done via custom script without any help from the Hobbit client.
I guess what I'm looking for is a hobbitfetch variant that uses ssh/scp rather than connecting to a msgcache listener. And along with that, a way to configure the client to collect data normally, but skip starting a listening service.
hi,
there should be a bb-central set of script at deadcat.net. those scripts works the following : the server generates scripts to collect th edatas on the clients. the scripts are copied then executed via scp/ssh on the client. the server parses the datas collected, and push the infos to the hobbit server. this tool was created to work with bigbrother, but you can certainly use them with hobbit. start with a small config, as you can have some bugs because these are quite old.
hope this'll help.
participants (4)
-
gjohnson＠trantor.org
-
haertig＠avaya.com
-
hobbit＠epperson.homelinux.net
-
pkc_mls＠yahoo.fr