Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am looking at securing my sendmail using stunnel. From what I have read it seems to be fairly straight forward, but I don't understand some things.
The way I understand mail transport, it will go from my home system to my mail server (which I am configing to use stunnel), then my mail server will locate the destination server, negotiate and send the mail. Once the mail is sitting on the destination server, the recipient will then either through web based, or pop3, pickup the email. My question is, doesn't the secure transmission thus end the moment my mail server begins negotiation with the destination server (assuming the destination isn't using secure SMTP.) If this is the case, how can I get around this, is the only way through Public/Private Key? Thanks in advance!
K, in your opinion do you think this scenario is secure:
I have a webstore program that sends orders via SMTP to users on the server it is running on. Doesn't that mean that it never actually leaves the server, and is secure as a result, as far as people not having access to it, as long as there isn't a hack or other form of intrusion.
(..)My question is, doesn't the secure transmission thus end the moment my mail server begins negotiation with the destination server (assuming the destination isn't using secure SMTP.) If this is the case, how can I get around this, is the only way through Public/Private Key?(..)
If the remote side doesn't want SSLified traffic you're right, it ends at your SMTP server. Message encryption IMO is the only way because SSLifying shields only traffic, not storage, and can't do sender/msg verification on retrieval.
*Btw, I've seen a pkg doin GPG automatic signing tru sendmail (not tru a MUA), but I haven't been able to tinker with it, and I don't know if this could be used on multi-user hosts.
Originally posted by mikeyt_333 K, in your opinion do you think this scenario is secure:
I have a webstore program that sends orders via SMTP to users on the server it is running on. Doesn't that mean that it never actually leaves the server, and is secure as a result, as far as people not having access to it, as long as there isn't a hack or other form of intrusion.
TIA
Mike.
/* Hmm. tried to merge these two threads as I'm sure this was your reply, but somehow the reply got stuck in the middle :-] */
Now for an answer I couldn't say it's secure without checking all the gory details, but if the webstore's scripts are checked for exploits/vulnerabilities, possibly using SMTP listening on the local interface with a restricted config, preferable w/o regular user shell accounts, and not doubling as server for the usual suspects of vulnerable services I'd say you've taken some steps ensure integrity, but I'm sure I'm forgetting some.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.