How to lockdown mail server

We use McAfee's SaaS Email Protection as a anti-spam gateway. Our MX records are properly set up so all mail to the domain goes through the gateway. However, we have found that some spammers are able to bypass the service entirely by sending mail directly to the IP address instead of the MX record.

McAfee says this:
Lock Down
Prevent attackers from bypassing the SaaS Email Protection by configuring your email server or firewall to only allow SMTP connections from the IP space used by the service.
Here are the IPs in various notation types. If you provide these to your e-mail provider, they should be able to lock down your e-mail connection to only accept inbound mail from McAfee EPS and prevent this type of message from reaching your firm in the future.

I have the IP list from McAffee in CIDR/21 and CIDR/24 formats as well as individual IP addresses. I manage the email server myself, but not sure where or how to enable this. Perhaps in /usr/etc/access ?

I do not believe the configuration is specific to FreeBSD platform, probably any Linux or other server running Sendmail.

Looking for some instructions on exactly how to configure this. Thanks in advance!
datastarstarAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

datastarstarAuthor Commented:
Here is what I tried in /etc/mail/access
localhost OK
From:1 REJECT
From:2 REJECT
...
From:254 REJECT

From:[IP1 of spam gateway] OK
From:[IP2 of spam gateway] OK
...etc

Testing this now, but is there a shorthand way of specifying the IP lists? (CIDR format?)

Will this work? Any risks?
0
Jian An LimSolutions ArchitectCommented:
i am not good in linux but i will try to do this on firewall level.

remove inbound source address *.*.*.* to internal IP port 25
add inbound CIDR/21 to internal IP port 25
add inbound CIDR/24 to internal IP port 25
0
arnoldCommented:
Do you have multiple public IPs? If so your firewall should only allow port 25 connections on the IP where MX points.

Your likely issue is you have mail.yourdomain.com or SMTP.yourdomain.com which is what is being used to send messages through.

Routing all SMTP through the mcaffee app will solve your problem but possibly capture/reject users attempts to send emails .....
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

datastarstarAuthor Commented:
Unfortunately, I do not have access to the firewall to add or modify rules. There are only preset firewall security options (low/medium/high) which I can't change to add/deny specific IP access to port 25.

Arnold, you are correct that we use mail.yourdomain.com for sending messages. I believe we have the option to use the McAfee service for outbound mail (SMTP) (we currently use it for inbound only). I understand all users would need to change their mail settings on any device they are using. But even if we did this, couldn't a spammer to bypass this as well? How would we prevent that?
0
arnoldCommented:
You simply need to make DNS change for mail.yourdomain.com to point to the IP on which mcaffee inbound connection ihandler s.  
The other option is to first configure that authentication on the incoming side,
Then require authentication on the incoming side.  

Make sure the requirement is just for the user and not for all.
0
datastarstarAuthor Commented:
I'm not sure I understand.

We already have MX records for domain.com which point the the McAfee service.

mail.domain.com is used for outbound only (I think, or is this what spammers are using to get around the MX record?)

What do you mean by this:
The other option is to first configure that authentication on the incoming side,
Then require authentication on the incoming side.

What authentication?
0
arnoldCommented:
Only you can answer how the messages are getting into your system.
outbound for users to send when the email is addressed to an internal user, that email turns out to be inbound as it will never be sent back out through the Mcaffee.

One option is to have all messages incoming, as well as those your users send go through the Saas application.

Does your outbound setup require the users to authenticate first before any email is accepted?
Make sure that this is a delicate step.  You have  to have two separate handlers.
One listening on port 25 accepting emails from mcaffee.
One listening on a separate port .. that is publicly referenced as mail.yourdomain.com and will require authentication for everyone.

try it. if you connect to mail.yourdomain.com from anywhere and you are not required to authenticate, you will be denied the ability to send email to external resources without authentication, but if you send an email to anyuser@yourdomain.com the message will likely be accepted as it is seen as an inbound and valid.
0
datastarstarAuthor Commented:
Our outbound email requires authentication.

Here is some new information:

I have checked using telnet for open mail ports.

My current configuration blocks all telnet requests to port 25 either by the domain or the IP address.

But port 587 will accept a request and send mail.

I am looking at ways of dealing with this using the sendmail config file.

Will FEATURE(`relay_based_on_MX')  force all mail connections to go through the MX record? Is there any other config option which will do what I need?
0
arnoldCommented:
The issue is not relaying as internally destined emails are accepted and delivered no relaying involved.
The question is whether you require authentication before accepting any email for processing on port 587.

Unfortunately, me sendmail .......
What you need  is that sendmail on port 587 will not accept any email until the user authenticates.
This presumes that this is how spam is getting in.
telnet server 587
repeat the SMTP example and see whether an unauthenticated user sending an email to user@yourdomain.com will receive a message that the message is accepted or rejected as soon as the sender is identified mail from: with a response 5xx authentication required.

Be carefull with this though I am uncertain how you can apply the requirement for authentication on port 587 only with sendmail without running two instances, one what you have and one that is only bound to port 587 and only handles incoming.
Do not force authentication without testing sendmail confguration on a test system.
0
datastarstarAuthor Commented:
If I telnet SERVER 25, the connection is blocked.

If I telnet SERVER 587, the connection is allowed and I can send mail from my personal gmail account to my email address on SERVER.  The message is received directly from the server without going through the MX record (McAfeee service).

I guess I need to figure out how to configure sendmail to disallow this type of attempt.
0
datastarstarAuthor Commented:
Just to clarify my last comment... When I said "I guess I need to figure out..." I meant "I need help figuring this out."

Any thoughts about how to do this? Here's a full transcript of my testing:

telnet xx.xx.xx.xx 25
Connecting To xx.xx.xx.xx...Could not open connection to the host, on port 25:
 Connect failed

telnet xx.xx.xx.xx 587
220 MYSERVER.com ESMTP Sendmail 8.14.5/8.14.5; Sat, 19 Sep 2015 07:07:47 -0400 (EDT)
HELO MYSERVER.com
250 MYSERVER.com Hello pool-xxx.xxx.xxx.xxx.xxx.xxxxxxxxxxxxx.fios.verizon.net [xxx.xxx.xxx.xxx], pleased to meet you
MAIL FROM:<ME@gmail.com>
250 2.1.0 <ME@gmail.com>... Sender ok
RCPT TO:<ME@MYSERVER.com>
250 2.1.5 <ME@MYSERVER.com>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
testing
.
250 2.0.0 t8JB7l0q092325 Message accepted for delivery

That message was received by ME@MYSERVER.com without going through the MX record holder. This is what I need to prevent. How?
0
arnoldCommented:
you need to add to the sendmail config set to listen on port 587, requiring authentication.
http://www.sendmail.org/~gshapiro/8.10.Training/DaemonPortOptions.html
test Using Modfier=a (M=Ea)

Test by adding another option to listen on port 900 (testing only)
with the M=Ea.use daemon=outgoing.myserver.com as well this way the Message header will also reflect info pointing to the source.
Once sendmail restarts, repeat the above example while connecting to port 900 and see whether you can issue a mail from: without authenticating first.
If that works, change the modifiers on port 587 to enforce authentication, removing the 900 test setting. and that is it.
0
datastarstarAuthor Commented:
I ended up going back to square one and approaching this from the firewall end. It turns out, I was wrong when I originally said I did not have access to firewall rules. The server is running IPFILTER and I was able to change the ruleset to block port 587. Mail seems to be coming through (in & out) with no issues and I can no longer connect to port 587 via telnet (which is good). It has been less than 24 hours, but so far I have not received mail from any spammers bypassing the McAfee service (typically I get a few each day).

I am going to give this another day or so before closing and awarding points.
0
arnoldCommented:
Do you,your internal users access and send email while offsite/remote? If so, your change is such that they are no longer able to respond when offsite/remote.

The M=Ea option on the port 587 Daemon option, would require authentication before mail can be sent on that port without regard to destination.  Your current option is likely M=E meaning it will only allow relaying after authentication.  Emails destined to your own domains will be accepted without authentication.
0
datastarstarAuthor Commented:
The following are the only 2 Daemon option lines in my current config:
DAEMON_OPTIONS(`Name=MTA-v4, Family=inet')
DAEMON_OPTIONS(`Name=MTA5190-v4, Family=inet, Port=5190')

Are you suggestion that I add something like this:
DAEMON_OPTIONS(`Name=MTA587, Family=inet, Port=587 M=Ea')

What is the 'name' field -- is that arbitrary or does it need to match something else?
0
arnoldCommented:
Name is what will be affiliated in the log/headers.

Try a different port than 587 to test the implication of M=Ea
Is your firewall routes port 587 to 5190?

Not a sendmail... But I think if you do not use daemon_options some ports are listened to/handled by default.

netstat -an | grep -i 'listen'
The above will display a list of IPs:ports that you gave applications bound for incoming connections.
0
datastarstarAuthor Commented:
Adding a daemon_option with M=Ea did not seem to make a difference.
netstat shows listening on all relevant ports (25, 587, 5190, etc.)
I don't see anything in the firewall rules about 587 to 5190
0
arnoldCommented:
To which entry did you add the M=Ea?
There are default ports,
Try the following
add
DAEMON_OPTIONS(`Name=auth_required_test_port, Family=inet, Port=3254', M=Ea)
once you restart sendmail, look whether port 3254 is among the ones you posted before.

now use telnet localhost 3254
ehlo servername
mail from: <youremailaddress>
and see whether the response is 5xx you must authenticate first or something like that .
This is what you want on your external 587 such that people will have to authenticate first before they are authorized to send email through this connection to your domain or to relay through your server.

Please look at the sendmail links provided earlier as they describe the options.
0
datastarstarAuthor Commented:
Added the daemon option line & restarted sendmail.
Not listening on port 3254 (via netstat) and telnet can't connect to it.
0
arnoldCommented:
I gave a typo, extra ' it might gave lead to that line being rejected.
Check /var/log/maillog to see if it reflects an error in the line preventing ......
0
datastarstarAuthor Commented:
Fixed the typo. Didn't seem to make a difference. There was no log error, btw.
0
arnoldCommented:
I do not think your config option took as it would have errored out, or would bind.


But if you are satisfied with the setup after your adjustment, that the firewall addressed your situation.
0
datastarstarAuthor Commented:
Unfortunately, the firewall "fix" didn't fix it after all -- messages are still bypassing the McAfee service.

Looking at this now from another angle:
/etc/hosts.allow

But when enabled, (commented ALL : ALL : allow) the example code blocks my pop mail app from checking mail even when I add:
qpopper : ALL : allow
0
arnoldCommented:
Pop3d:allow
Apogee:allow

Is the correct formatting for /etc/hosts.allow, /etc/hosts.deny

You gave to identify how it is e tearing your setup.
0
datastarstarAuthor Commented:
As soon as I add those lines and comment "ALL : ALL : allow" I get an error checking mail

What is this ??
"You gave to identify how it is e tearing your setup."
0
datastarstarAuthor Commented:
If this helps, my pop3 mail app is Outlook. It used port 110 by default for inbound mail.
0
datastarstarAuthor Commented:
And for more help, here is what is currently included in hosts.allow. Would any of this block pop3 mail checking?

#ALL : ALL : allow
Pop3d : ALL : allow
Apogee : ALL : allow
qpopper : ALL : allow

ALL : PARANOID : RFC931 20 : deny

ALL : localhost 127.0.0.1 : allow

ALL : [::1] : allow

sendmail : localhost : allow
sendmail : ALL : allow

exim : localhost : allow
exim : ALL : allow

rpcbind : ALL : deny

ypserv : localhost : allow
ypserv : ALL : deny

ALL : ALL \
        : severity auth.info \
        : twist /bin/echo "You are not welcome to use %d from %h."
0
arnoldCommented:
The difficulty here is you are trying to solve a problem where you've not identified it.

You might be working in the mail server while the messages wind up in your system by way of a web server, a compromised user account whose credentials are being used to send out messages, a compromised user's system that has a bot/etc that is the source of these mailings.


you should first confirm that the messages really originate from your system, you could configure your mail server to reroute through mcaffee outgoing filtering to have it capture spam on e outgoing side.


Usually, the hosts.allow and hosts.deny work
By adding a deny entry to hosts.deny

Deny
Smtpd:ALL

Allow entries will be the exclusions to the rule.

Your formatting of the entries are not what I recall them to be
They are usually
Service:host
Service:x.x.x.x/24
Etc

The entry being in hosts.deny means what entry there is it will be denied when matched.
The same applies to hosts.allow

Since the deny list is not e enforcer, commonly when there is no need to have access,
Hosts.deny had all:all
Then hosts.allow would have the entries for access that should be allowed
SMTP:all
.....

I still think I this situation, you've taken many steps, but to date it is not clear to me the originating system that generates them nor is it clear that your server is the source.

A bounce back that has the sender as return-path: <>

Means it is a bounce, non deliverable reply/response ......

Not sure whether mcaffee handling of outbound, but you could try it while monitoring its performance to make sure you are not sacrificing .........
Smarthost on your mail server route through mcaffee rather than have it deliver to the final destination.
0
datastarstarAuthor Commented:
On FreeBSD, hosts.deny is deprecated and everything goes into hosts.allow. That is why there is an extra parameter (:allow | :deny) at the end of service:host

"I still think I this situation, you've taken many steps, but to date it is not clear to me the originating system that generates them nor is it clear that your server is the source."

I agree -- it's not clear to me either.

A normal mail header begins like this (mxlogic is the McAfee service):
Return-Path: <xxx@legitsender.com>
Received: from s12p02m085.mxlogic.net (mxl145v246.mxlogic.net [208.65.145.246])
      by MYSERVER.com (8.14.5/8.14.5)

A message from a spammer that bypasses it looks like this:
Return-Path: <sisir@trini.beewh.com>
Received: from trini.beewh.com ([112.26.75.157])
      by MYSERVER.com (8.14.5/8.14.5)

Does that help?
0
arnoldCommented:
Yes, the second message said the message originated from trini.beewh.com ip 112.26.75.157

Your system/users are the destined recipients if spam, any messages going back out are bounce backs, failure to deliver notices, non-deliverable response to what ever email address was provided as the sender.

Look at using anti-spam/virus for sendmail including using rbl lists that will deny known spammers identified by lists you choose from connecting to your server.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
datastarstarAuthor Commented:
Arnold, thank you for sticking with me on this one. As you know, I've tried many different approaches on the issue, and as you've pointed out, often without considering the true cause of the problem in the first place. So in the end, I enabled an rbl list in my sendmail config (zen.spamhaus.org). Problem solved.

Thanks again!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Email Servers

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.