where docs on *REMOTE* logging using ssh??
Where can I find docs on setting up secure (SSH) remote syslog-ng logging? Chris -- _______________________________________ Dr. Christian Seberino SPAWAR Systems Center San Diego Code 2363 49590 Lassing Road, Room A339 San Diego, CA 92152-6147 U.S.A. Phone: (619) 553-7940 Fax: (619) 553-1269 Email: seberino@spawar.navy.mil _______________________________________
On Tue, Jan 28, 2003 at 11:21:42AM -0800, seberino@spawar.navy.mil wrote:
Where can I find docs on setting up secure (SSH) remote syslog-ng logging?
People tend to choose stunnel, you could modify the instructions appropriately, though. Be sure that if you use ssh that the account doesn't allow general login - its probably for fear of account misuse that people don't use ssh. Well, that and no built-in mechanism to reconnect if the connection drops. The right place to start is with your (openssh) authorized_keys file having settings like this: no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3N... syslog-ng@remotehost "logging account only" Anyways, most people who need instructions on setting ssh port forwarding shouldn't use it for syslog traffic. Use stunnel and you'll be better off. -- Nate Campi http://www.campin.net A complex system that works is invariably found to have evolved from a simple system that worked. -John Gall
On Tue, Jan 28, 2003 at 11:57:14AM -0800, Nate Campi wrote:
The right place to start is with your (openssh) authorized_keys file having settings like this:
no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3N... syslog-ng@remotehost "logging account only"
Haha, I crack myself up. I actually put in "no-port-forwarding" when answering a post about using ssh for just such a purpose. What a dufus. Anyways, the rest of what I said still applies. :) HINT: if you use ssh and want it to reconnect, set it up under daemontools <URL:http://cr.yp.to/daemontools.html> so that when it dies it starts right back up, and the output is properly logged with multilog (assuming you set up logging, which you should). Also look into forced commands if you want better security. You won't be forwarding straight into syslog-ng, but you'll rest better knowing you're doing as much as you can to prevent misuse of this account. Did I mention that stunnel makes it so you don't need to worry about all this? -- Nate Campi http://www.campin.net Without C, We would only have Pasal, Basi, and obol
Nate Thanks. This is all good info. From what you've said I'm sure stunnel is easier and better for this little job. My only hesitation in using all these handy little lesser known tools is whether they have the same auditing/inspection of their source code like openssh does. OpenSSH is very widely used and many people analyze the code for defects daily. It is widely trusted and from a reputable source (OpenBSD guys). It would be safe and useful to invest my time in openssh since it will be around forever.... I don't know about stunnel though. Then again what do I know?... Chris P.S. I'm still surprised syslog-ng has no docs on remote logging and even docs for using syslog-ng with ssh or stunnel are hard to come by. On Tue, Jan 28, 2003 at 01:05:48PM -0800, Nate Campi wrote:
On Tue, Jan 28, 2003 at 11:57:14AM -0800, Nate Campi wrote:
The right place to start is with your (openssh) authorized_keys file having settings like this:
no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3N... syslog-ng@remotehost "logging account only"
Haha, I crack myself up. I actually put in "no-port-forwarding" when answering a post about using ssh for just such a purpose. What a dufus.
Anyways, the rest of what I said still applies. :)
HINT: if you use ssh and want it to reconnect, set it up under daemontools <URL:http://cr.yp.to/daemontools.html> so that when it dies it starts right back up, and the output is properly logged with multilog (assuming you set up logging, which you should). Also look into forced commands if you want better security. You won't be forwarding straight into syslog-ng, but you'll rest better knowing you're doing as much as you can to prevent misuse of this account.
Did I mention that stunnel makes it so you don't need to worry about all this? -- Nate Campi http://www.campin.net
Without C, We would only have Pasal, Basi, and obol
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html
-- _______________________________________ Dr. Christian Seberino SPAWAR Systems Center San Diego Code 2872 San Diego, CA 92152-6147 U.S.A. Phone: (619) 553-9973 Fax: Email: seberino@spawar.navy.mil _______________________________________
On Tue, Feb 04, 2003 at 04:24:07PM -0800, seberino@spawar.navy.mil wrote:
Thanks. This is all good info. From what you've said I'm sure stunnel is easier and better for this little job. My only hesitation in using all these handy little lesser known tools is whether they have the same auditing/inspection of their source code like openssh does.
OpenSSH has had plenty of security problems, it's never been demonstrated that the OpenBSD audits really help anything. The main key to their good security record is due to the fact that most services are shut down by default.
OpenSSH is very widely used and many people analyze the code for defects daily. It is widely trusted and from a reputable source (OpenBSD guys). It would be safe and useful to invest my time in openssh since it will be around forever.... I don't know about stunnel though.
Even if openssh itself has no security holes, that's not the point. The points I brought up were concerned with misuse of the shell access openssh grants. THAT's what I'd be scared about if I were you. Anyways, I tunnel all kinds of crap with SSH port forwarding, I just don't think it's the best solution for most situations. There aren't any docs needed for syslog-ng using a tunnel, since the docs with stunnel or ssh related to tunneling with TCP apply to any TCP traffic. Look for docs with those tools and you'll be fine. -- Nate Campi http://www.campin.net
Even if openssh itself has no security holes, that's not the point. The points I brought up were concerned with misuse of the shell access openssh grants. THAT's what I'd be scared about if I were you.
This is only an issue if you don't take the time to setup the tunnel properly. Use a non-root account created only for the purpose of tunnels (with a locked password and a bogus shell), setup the authorized_keys file with command="/bin/false" so they CAN'T run any commands, and then use the -N flag to ssh to not execute a remote command when you setup the tunnels. We use reverse tunnels all over the place at work for logging and other stuff that needs to pass back through the firewall from the DMZ networks. A secure server inside the wall opens an SSH connection to the DMZ server, then forwards a port back through the tunnel to the server. The DMZ server never has to know anything about the secure server, nor be able to connect to it directly. This opens a small security hole in that if the DMZ host is compromised the bad guys have a single port they can access into the internal network, but we mitigate that risk by running syslog-ng on the secure server non-root and chrooted. *b -- People who are willing to rely on the government to keep them safe are pretty much standing on Darwin's mat, pounding on the door, screaming, "Take me, take me!"
On Wed, Feb 05, 2003 at 10:04:43AM -0500, Brian Landers wrote:
This is only an issue if you don't take the time to setup the tunnel properly. Use a non-root account created only for the purpose of tunnels (with a locked password and a bogus shell), setup the authorized_keys file with command="/bin/false" so they CAN'T run any commands, and then use the -N flag to ssh to not execute a remote command when you setup the tunnels.
The point is that stunnel solves the problems that need addressing with using ssh (not giving shell access, automatic reconnects). I've already stated that I use SSH tunnels, I usually don't recommend them as a starting point when it appears people are struggling with getting their whole loghost system up and running. -- Nate Campi http://www.campin.net
participants (3)
-
Brian Landers
-
Nate Campi
-
seberino＠spawar.navy.mil