[ossec-list] Re: Integrity Checks and Diffs?

["Marty E. Hillman" <mehillman@xxxxxxxxxxxx>]

> 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.