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:
0. Allow IP In&Out from zone[MyLAN] to zone[MyLAN]
1. Allow IP In&Out from zone[MyLAN] to zone[Multicast]
2. Allow TCP Out from MyServer to ISP.Mail.Server port 25
3. Block TCP Out from zone[MyLAN] to any port 25
4. Block TCPorUDP Out from zone[MyLAN] to any port 135,137,138,139,445
5. Allow TCPorUDP Out from zone[MyLAN] to any
6. Allow ICMP Out from zone[MyLAN] to any
7. Block IP Out from zone[MyLAN] to any
8. Allow ICMP In from any to any where ICMPmessage is PortUnreachable
9. Allow ICMP In from any to any where ICMPmessage is HostUnreachable
10. Allow ICMP In from any to any where ICMPmessage is TimeExceeded
11. Allow ICMP In from any to any where ICMPmessage is FragmentationNeeded
12. Allow ICMP In from any to any where ICMPmessage is NetUnreachable
13. 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 <bleep> 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?
