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.
How do you know they are getting a shell.
It's more likely they are using the command "telnet your_emails_servers_ip 25" and then spoofing the HELO and from address info to your internal users email addresses.
Sounds like your email server is set-up incorrectly and allows relaying.
Supply more info on email server type, version and what makes you think they have telnet access.
Sorry for the wait time, we have found the following(after looking at logs for days).
It was not an external telnet, it came from a machine inside our intranet. This was found out after some time. The original person(s) logged into one machine, telneted another, and then sent the e-mails. This way, the machine name in the sendmail log showed the second machine's name. Then after looking for a telnet session in the logs, did we find that that machine was telneted to(OOOoohhh, tricky).
The user name of the person from who the e-mail was not a valid user name at our company.
The account that was used to login with is a student account that has been used for months now.(I know, I know, that was one of the other sys admins idea, he's taking the heat for that now). That is a dead end since we have no cameras or records.
We cannot block the internal telnet for the student machine since it is used in the class.
Sendmail is blocked on the classroom machines, so it could not have been used, hense the "telnet" lead.
There must be some sendmail config that will not except connections like this???
We are using sendmail ver. 8.8.3, later, after gettting some more machines up, this will change, but not for a few months, you know with this kick ass economy and all, were just spending away, not.
I would look at the FEATURE(`relay_mail_from') option where you specify real user names that are allowed to relay
or
FEATURE(`access_db')
FEATURE(`access_db', `hash /etc/mail/access')
The access_bd feature where you build up a list of users who are allowed access to the mail services, a fake user would be rejected.
Also a check from the Header id to confirm user id so faking a known user is rejected with an incorrect message id.
Someone who knows more about sendmail then I do, could give you more info on these options then in the anti spam FAQ.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.