Hi All,
I operate a mail server for my home/office intranet. I want to block access from the internet to keep spammers from using my mail server. At the same time, I still want my intranet to have access to the mail server.
Nothing I have tried seems to work, it blocks internet access but also blocks intranet access.
How do I block port 25 so no access is given to the internet but still allow access from the intranet?
Thanks for any help,
Charles
Charles,
Do i understand it correctly that you don’t want to send and receive email from other domains then the internal one ?
If you block port 25 for incoming traffic other mail server can no longer deliver mail for your domain.
If you block port 25 for outgoing traffic from your mail server then you can no longer deliver email to “other” domains.
Welcome to the forums, CharlesEF
Speaking as a dayjob LAN/email admin, let me say “Thank You!” for trying to do the right thing to keep the spammers at bay.
I’m a little confused about your networking setup. One persons intranet is another persons extranet is another persons VPN with routing. Terminology can be confusing, obviously. But wiring, I can understand.
Since you’re saying “home/office”, I’m going to guess this kind of network layout
client office — ISP ---- Internet ---- ISP ---- NAT/router? -±— home mail server
±— other PC’s and networked devices
And you’re wanting to protect the home mail server, yet make it accessible from the client office, and not allow the spammers to get at the mail server.
Is this a good guess?
Hi,
Port 25 is for SMTP (sending e-mail). I want to block anyone from using port 25 if the connection comes in over the internet. But I want to allow port 25 to be used if the connection is from my local network (intranet).
I have a simple network, no servers/clusters/Active Directory or routers, I only use a Workgroup name and a hub.
I am not worried about VPN or any other thing. I will never access my mail system over the internet and I do not want anyone else to either.
My mail server consists of the following:
SMTP Process - handles out going mail from local network (intranet)
POP3 Process - handles distribution of mail to the local network
SMTP Client - handles sending out mail from the local network to my mail server located on the web
POP3 Client - handles receiving mail from different POP3 addresses and my domain to distribute to my local network
I want the SMTP Process to accept out going mail from my local network only, regardless of which port number I use. The SMTP Client already uses a different port number, not 25, to send out mail.
I tried setting up a rule that blocks port 25 if it is not in the local zone (I setup a local trusted zone). But each time I start the mail server program Comodo pops up a warning box and I click ‘Allow’ and also check the remember checkbox. After this I see that my rule is gone.
Thanks for any help,
Charles
Fairly straightfoward. I do want to confirm first, that you are running CFP v2.4 and I would guess that you’re on a WinXP box. If it’s blue shield in the system tray, then you’re most likely CFP v2.4. If it’s a white shield, then you’re likely CFP v3.
These are the two rules you’ll need to add in CFP v2.4. Open CFP, click Security → network Monitor, and Add
Action: Allow
Protocol: TCP
Direction: In
Source IP: Zone[MyLAN]
Destination IP: Single IP:
Source Port: Any
Destination Port: a single port: 25
Action: Block
Protocol: TCP
Direction: In
Source IP: Any
Destination IP: Any
Source Port: Any
Destination Port: a single port: 25
These two rules will be added at the end of the CFP rules. CFP process rules in sequence, from the top, first match wins. You will need these two rules so they come first at the very top.
the Zone[MyLAN] is where you get to specify which IP addresses are on your local network. Click Security → Tasks, and then click “Add/Remove/Modify a Zone”. You probably already have one for your local network, but I’ll assume adding a new zone, just to be sure. To Add, you’ll give it a name (like “MyLAN”), and then the boundary addresses, like 192.168.0.0 and 192.168.0.255.
Are you running a Windows ICS host, and this host is also where you’re running your mail server? If so, then you’ve got two IP addresses for the machine. The LAN side of your server is 192.168.0.1, and the Internet address is something else. It’s the LAN-side address that is in the CFP “allow” rule, and not the Internet address.
You can use “ipconfig /all” from a command prompt to check what IP addresses are present.
Your description reminds me of Mercury/32 configuration. I’ve worked with that environment before.
Hi,
Yes, it is the Mercury/32 mail server program I use. I used your instructions to block incoming mail over the internet. It seems I was in the wrong place to begin with and I only setup half the rules I needed.
I was creating a ‘Block’ rule in the ‘Application Monitor’ not the ‘Network Monitor’ section.
BTW, I use Win2000 Pro so I am forced to use v2.4 and I also run a gateway program.
Thank you very much for your help,
Charles
Good rule of thumb is;
Inbound data is parsed by the network monitor first and then passed to the application monitor.
Outbound data is parsed by the application monitor first and then passed to the network monitor.
Cheers,
Ewen 
P.S. How good is Mercury? I’m currently evaluating Ability Mail server and it looks bloody good.
Hi panic,
Mercury/32 is an excellent mail server program. I do not know anything about Ability so I can not compare features. After looking at the Ability web site I see that it indeed seems like an excellent program also. I know the webmail interface part of Ability does not exist in Mercury/32. The author wants to add that also but at this time it is missing.
Also, Mercury/32 is free compared to the Ability price of over $100.00
Mercury/32 can be found at: http://www.pmail.com
Hope this helps,
Charles
So you have the rules in place? If so, how is it working? If it isn’t working as you expect, then I’ll ask to see you Network Monitor rules. That takes making a screenshot (alt-prntscrn, paste into Paint (or some other such app), save as a file, and attach to a post you make here)
Regarding web mail: all web mail is, is a front-end to an IMAP server. IMAP was designed for use on a LAN, and the regular email clients work with it as a matter of routine. Putting a web front end client on the LAN server was the simple way of deploying mail services to ISPs that cut way down on their customer service needs to explain how POP email works (or, mostly didn’t work, why else call customer service). If you have IIS or some other web server, then the only connecting piece you need is something like SquirrelMail (http://www.squirrelmail.org/), then you’re all set.
It would probably be a good idea to check your server ports being exposed to the Internet. From a command prompt, run “netstat -an”. If you see any mail server ports exposed, you will need CFP rules to shield those also.
Spammers, and malware, will search for POP (port 110), IMAP (port 143), and mail submission (port 587) exposed ports to attack weak passwords and authentication lapses.
edit: added SquirrelMail detail for webmail setup
Thanks Charles. Mercury looks good, but the fact that Ability has its own LDAP 3 server embedded is it’s real attraction for me (looking to unify logins iwth LDAP and Kerberos ticketing on a small-ish LAN).
Cheers,
EWen
Hi grue155,
Yes, the rules are in place and appear to be working correctly. My log already shows lots of attempts to access port 25 from outside sources (not my IP number range). Good idea about the extra ports you pointed out. I will add rules for 21, 110, 143 and 587.
This is the result of the command: netstat -an
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:21 0.0.0.0:0 LISTENING
TCP 0.0.0.0:25 0.0.0.0:0 LISTENING
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
TCP 0.0.0.0:110 0.0.0.0:0 LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1028 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1030 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1034 0.0.0.0:0 LISTENING
TCP 127.0.0.1:2220 127.0.0.1:2221 ESTABLISHED
TCP 127.0.0.1:2221 127.0.0.1:2220 ESTABLISHED
TCP 127.0.0.1:2222 127.0.0.1:2223 ESTABLISHED
TCP 127.0.0.1:2223 127.0.0.1:2222 ESTABLISHED
TCP 127.0.0.1:2233 127.0.0.1:2234 ESTABLISHED
TCP 127.0.0.1:2234 127.0.0.1:2233 ESTABLISHED
TCP 127.0.0.1:2235 127.0.0.1:2236 ESTABLISHED
TCP 127.0.0.1:2236 127.0.0.1:2235 ESTABLISHED
TCP 127.0.0.1:12025 0.0.0.0:0 LISTENING
TCP 127.0.0.1:12080 0.0.0.0:0 LISTENING
TCP 127.0.0.1:12110 0.0.0.0:0 LISTENING
TCP 127.0.0.1:12119 0.0.0.0:0 LISTENING
TCP 127.0.0.1:12143 0.0.0.0:0 LISTENING
TCP 172.16.1.0:139 0.0.0.0:0 LISTENING
TCP 216.126.173.145:139 0.0.0.0:0 LISTENING
TCP 216.126.173.145:2268 72.14.207.127:80 LAST_ACK
UDP 0.0.0.0:135 :
UDP 0.0.0.0:445 :
UDP 0.0.0.0:1029 :
UDP 0.0.0.0:1031 :
UDP 0.0.0.0:1035 :
UDP 0.0.0.0:3456 :
UDP 127.0.0.1:1032 :
UDP 172.16.1.0:137 :
UDP 172.16.1.0:138 :
UDP 172.16.1.0:500 :
UDP 172.16.1.0:520 :
UDP 172.16.1.0:4500 :
UDP 216.126.173.145:137 :
UDP 216.126.173.145:138 :
UDP 216.126.173.145:500 :
UDP 216.126.173.145:520 :
UDP 216.126.173.145:4500 :
Are there any other ports you would recommend I close down? Maybe port 21 because I do not want anyone to FTP into my computer? But, since I do not run an FTP server would a rule still be required?
Also, I have 1 more question if you don’t mind. My log shows lots of outbound ICMP: PORT UNREACHABLE errors. I have checked and these are DNS queries sent from my computer to my ISP’s DNS server. I have not added any rules that would affect port 53, at least I don’t think so. Unless Comodo has default entries which I do not see. Should I add an ‘Allow’ rule for these outgoing queries?
Thanks for your help,
Charles
You’ve got yourself a bunch of ports there 
And maybe some of them you don’t want exposed to the Internet. Rather than nailing down individual ports, let’s take it from the other direction. Let’s lock down all the ports, and then open up the ones that are supposed to be open.
I’ll outline what I’ve got in mind, and use a somewhat abbreviated rule notation, so you can have a better chance of understanding what I’m working at.
Here’s a proposed ruleset:
Allow IP In&Out from zone[MyLAN] to zone[MyLAN]
Allow IP In&Out from zone[MyLAN] to zone[Multicast]
Allow TCP Out from MyServer to ISP.Mail.Server port 25
Block TCP Out from zone[MyLAN] to any port 25
Block TCPorUDP Out from zone[MyLAN] to any port 135,137,138,139,445
Allow TCPorUDP Out from zone[MyLAN] to any
Allow ICMP Out from zone[MyLAN] to any
Block IP Out from zone[MyLAN] to any
Allow ICMP In from any to any where ICMPmessage is PortUnreachable
Allow ICMP In from any to any where ICMPmessage is HostUnreachable
Allow ICMP In from any to any where ICMPmessage is TimeExceeded
Allow ICMP In from any to any where ICMPmessage is FragmentationNeeded
Allow ICMP In from any to any where ICMPmessage is NetUnreachable
Block IP In from any to any
Now what all that is trying to do:
Rules 0 and 1 are to let your LAN machines talk among themselves. The zone[Multicast] is often not considered in rules, but some functions use maulticast addresses rather than normal broadcast addresses. Multicast is a special broadcast LAN-only address range 224.0.0.0 thru 239.255.255.255.
Rule 2 and 3. Something maybe to consider, is restricting your mail server to be the only way to get mail out. That makes your Mercury/32 server a chokepoint. Everything comes and goes out thru it, giving you full logs of all email traffic. No LAN PC can bypass you, unless they got out to an ISP submission port (port 587). If that isn’t something you want, then add 587 to the list. I’m a dayjob email admin, and have found chokepoint useful to trap some machine that gotten infected and trying to spam the Internet or the LAN.
Rule 4. Windows will do some really weird things with it’s networking. And Windows networking was never intended to be exposed to the Internet. This rule makes sure it never does.
Rule 5,6,7. These let your LAN machines talk outbound to the Internet, and only using TCP, UDP, and ICMP. There are other protocols, rarely used. Rule 7, as a blocking rule, makes sure they won’t be.
Rules 8 thru 12. ICMP is the error message reporting method on the Internet. It’s the telephone equivalent of “sorry, no one home, voice mail is full, call back later,bye”. There are a bunch of error message, and these are the most common. If you let these come in, then your application will get the “no one home” message, and not sit there and keep retrying until something just times out.
Rule 13. This is the universal inbound blocking rule. Anything coming into your machine should be in response to something sent from your machine. CFP will recognize that traffic, and let it in. But if nothing is expected, this rule will keep the traffic out.
I’ve skipped logging details. You can set the alert/log flag as you want.
If you have any ports that you do want exposed to the Internet, you would need to add a rule between rules 12 and 13, something along this line
allow TCP In from any to any port 80
which would let somebody on the Internet connect to your web server (port 80), for example.
Does all that make any sense?
Hi,
Wow, that is some list. I will review all the items tonight and I am sure I will use all of them (at least most of them). I might be back once I install my SQL server and need to open ports 1432, 1433 (I think I remembered the correct ports). Hopefully I will be able to figure it out but it is nice to have a place to yell for help.
Thank you very much for your time and help,
Charles
Hi grue155,
One more question, please.
When I create a trusted zone Comodo creates 2 network rules. 1 for the inbound rule and 1 for the outbound rule. I deleted these 2 entries and replaced them with your 1 in/out rule. Do I still have a trusted zone defined now?
What about the ‘Multicast’ zone. Should it be a trusted zone or not?
I used all you suggestions and I added 1 more for SMTP port 587 and everything seems to be working great.
Here are the new results of the command: netstat -an
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:21 0.0.0.0:0 LISTENING
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1028 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1030 0.0.0.0:0 LISTENING
TCP 0.0.0.0:2348 0.0.0.0:0 LISTENING
TCP 66.19.5.58:139 0.0.0.0:0 LISTENING
TCP 66.19.5.58:3787 216.239.59.127:80 LAST_ACK
TCP 127.0.0.1:3709 127.0.0.1:3710 ESTABLISHED
TCP 127.0.0.1:3710 127.0.0.1:3709 ESTABLISHED
TCP 127.0.0.1:3711 127.0.0.1:3712 ESTABLISHED
TCP 127.0.0.1:3712 127.0.0.1:3711 ESTABLISHED
TCP 127.0.0.1:3724 127.0.0.1:3725 ESTABLISHED
TCP 127.0.0.1:3725 127.0.0.1:3724 ESTABLISHED
TCP 127.0.0.1:3726 127.0.0.1:3727 ESTABLISHED
TCP 127.0.0.1:3727 127.0.0.1:3726 ESTABLISHED
TCP 127.0.0.1:12025 0.0.0.0:0 LISTENING
TCP 127.0.0.1:12080 0.0.0.0:0 LISTENING
TCP 127.0.0.1:12110 0.0.0.0:0 LISTENING
TCP 127.0.0.1:12119 0.0.0.0:0 LISTENING
TCP 127.0.0.1:12143 0.0.0.0:0 LISTENING
TCP 172.16.1.0:139 0.0.0.0:0 LISTENING
UDP 0.0.0.0:135 :
UDP 0.0.0.0:445 :
UDP 0.0.0.0:1029 :
UDP 0.0.0.0:1031 :
UDP 0.0.0.0:2349 :
UDP 0.0.0.0:3456 :
UDP 66.19.5.58:137 :
UDP 66.19.5.58:138 :
UDP 66.19.5.58:500 :
UDP 66.19.5.58:520 :
UDP 66.19.5.58:4500 :
UDP 127.0.0.1:1901 :
UDP 172.16.1.0:137 :
UDP 172.16.1.0:138 :
UDP 172.16.1.0:500 :
UDP 172.16.1.0:520 :
UDP 172.16.1.0:4500 :
Should I create a rule to block inbound FTP port 21 and Telnet port 22 (I think)? Your suggestions are always welcome.
Thanks,
Charles
Yes, you can make a “Multicast” zone as a trusted zone. But multicast addressing is a strange beast, in that it can only be a destination address. The closest comparison I’ve ever heard of, is a bulletin board. People on a hallway (the machines on your LAN) will write to the bulletin board, and people will read what is on the bulletin board. But the bulletin board itself will never write to you.
Looking at the earlier rule 1 in my proposed ruleset
if you split it up, it becomes this
Allow IP In from zone[MyLAN] to zone[Multicast] # you reading what others write to the bulletin board
Allow IP Out from zone[MyLAN] to zone[Multicast] # your machine writing to the bulletin board
Multicast addresses can be immensely useful, and really confusing. Just look at Multicast - Wikipedia
About what rules you need to add? You shouldn’t need to add anything to block ports. Only to open up to allow access. With that proposed ruleset I gave, the very last rule
should block everything. The netstat report shows what ports Windows considers to be open, and doesn’t show anything about what CFP is doing to block anything. That’s just a limitation in how the tools work.
It would be a good idea to check that everything that should be blocked, really is blocked. The web site http://www.grc.com and its “Shields Up!” test is one of the best known. What you want to do, is to check very specific ports, which grc.com can do with it’s “User Specified Custom Port Probe”.
From your netstat report, you’d want to test anything with a local address of 0.0.0.0, or with your Internet-facing address (in your prior post, that was 66.19.5.58).
From those, the port list to check becomes: 21,80,135,443,445,1025-1031,2348,2349,3456,139,137,138,500,520, and finally 4500. Quite a list.
Unless you are explicitly providing an opening in the CFP ruleset, all of those ports should be reported as “stealth” by grc.com. “Stealth” means that grc.com can’t tell if there is a listening open port present or not, which means you are invisible to the Internet.
If you run the grc.com test, and anything comes back as other than “stealth”, then your CFP ruleset needs to be tweaked. In which case I’ll ask for a screenshot of your rules, and we go from there.
If all comes back as “stealth”, you’re all set, and safe on the Internet.
Hi grue155,
I went to the grc website and ran both the Custom and User Defined tests using the list of ports you gave me. Both tests returned passed with a perfect “TruStealth” rating.
This means I am done and should leave everything as is.
Thanks for your help,
Charles
[at] grue155,
Great job working through this. As always, highly eductional.
Cheers,
Ewen
Good to hear that is working. I’ll leave this topic open for a couple of days, in case any questions manifest themselves. Then I’ll lock it for reference. After that, if the topic needs to be reopened, just PM any of the moderators.
@panic. Thank you…
[at] grue155
How would you feel about turning this into a generic FAQ on how to tune access for an email server using CFP?
Just a simple one question - one answer, like the Backup FAQs.
Just a thought,
Ewen
There’s already some background work in progress, on the subject of email, and some other things. Soon, I hope.