> David Vasil Wrote: *snip*
> > This should redirect all port 25 traffic to the corresponding SMTP > port > > on the server. Just email at localhost. > > > > Setting up Cygwin to tunnel - > > http://pigtail.net/LRP/printsrv/cygwin-sshd.html > > This to me sounds worse than giving OSSEC a passphraseless gpg key... > In > this scenario you are giving OSSEC the ability to ssh to external > servers without a passphrase, be it through hostbased equivalency or > publickey authentication. > > Also, the message is only encrypted until it reaches the end of the > tunnel (unless all MTA hops are using TLS/SSL). If some password file > gets modified and a diff is sent to you, someone could capture that > diff, and extract authentication tokens for your site. > > Additionally, only root can forward privileged ports, so OSSEC would > have to run this as root =(. There really isnt a graceful solution to > this problem. The best answer so far seems to be locking down your > OSSEC server, give OSSEC a gpg key which you "somewhat" trust, and hope > your OSSEC system doesnt get broken into. My favorite answer so far is > "just dont send diffs automatically". > > -- > -dave You can set a passphrase for the root user and create the tunnel using that. The only port that my example gives access to is the SSH port and to no other (pending an as yet undiscovered hypothetical security exploit vulnerability in ssh). The SMTP traffic is directed to that port where it is then authenticated and passed to the local SMTP service. Using a passphraseless gpg key, you can connect to anyone. This forces all SMTP traffic to one destination, does it not? The point is that the message is encrypted across the tunnel. The traffic through the switches and routers is the vulnerable target in my example due to promiscuous monitoring and/or ARP cache poisoning. Tunneling it also prevents hazards from spoofed IP addresses because they would need to spoof the SSH cert as well. The point is to keep it encrypted when it is outside of a machine and on the wire. I agree the trick then becomes getting the mail server to send it encrypted to the recipient. But that one could most likely be overcome within the mail server software. I don't want to digress into how to configure mail servers for secure communications here. One could send the mail traffic through a separate interface and pray that this network segment is not hacked. True, only root can forward privileged ports, but you do not have to remain logged in as root in order for the port to remain forwarded. Many services run in privileged mode as root, don't they? Couldn't you script the opening of the tunnel (securing the script so that it only is accessible to root or sudo) and have it automagically occur if the computer should be reset? I am not sure what extra security risks one would be taking by doing this. My favorite answer is the same as yours. In a perfect world, only one answer would be needed. But as Erick's situation suggests, sometimes the undesirable is the best and most affordable approach to solving a problem. I am just brainstorming and trying to make it as secure as possible given my paranoiac tendencies. :) I know that eventually I will run into a customer that wants to take a similar approach to Erick and my powers of persuasion against it will dry up. I just figure this is a good opportunity to think of creative solutions to the problem. This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.
