Need Help Understanding Firewall Rules and DNS
-
Networking, DNS, Firewalls, are not my forte, but I'm trying to learn this step by step.
I have pfSense in a VM in front of a Windows Exchange Server, also in a VM.
The DNS is accessible from external by anyone, shows up in port scans as open, and as a result I've had off & on amplified DNS attacks.
I can't figure out how to close down the DNS to external access, while leaving the internal able to resolve and lookup incoming email domains.
I've read other threads here, but I'm not sure if my understanding and terminology is correct, as rules I've seen others recommend do not work for me. Its possible I don't have other aspects of pfSense properly configured.
What would be an working rule for this?
Any help appreciated.
~ Tom
-
On your WAN allow TCP port 25 in, so your Exchange server can receive mail from other mail servers - and the odd spambot, of course :)
Of course, you will need a NAT rule to get the incoming email traffic to your Exchange server. Creating the NAT rule can set up the WAN rule for you if you check the box.
If your Exchange server is on the LAN, it will automatically be able to lookup DNS because the default LAN rule is to allow everything.
If your Exchange server is on an OPT interface (a DMZ) you will have to allow TCP port 25 in on that interface, so Exchange can send emails, as well as TCP and UDP port 53 (DNS), so Exchange can look up destination mail server IP addresses.
DNS responses to the Exchange server will automatically be allowed back in through the WAN interface.
That's really all you should need. Hope I haven't forgotten anything - it's Friday night :)
Oh, one thing. The pfSense book.
-
Networking, DNS, Firewalls, are not my forte, but I'm trying to learn this step by step.
I have pfSense in a VM in front of a Windows Exchange Server, also in a VM.
The DNS is accessible from external by anyone, shows up in port scans as open, and as a result I've had off & on amplified DNS attacks.
I can't figure out how to close down the DNS to external access, while leaving the internal able to resolve and lookup incoming email domains.
Any help appreciated.
~ Tom
I'd recommend to never run a public DNS service (or any other service available "to any" for that matter) unless it is really necessary.
If you run a proper name server (BIND) you could set security settings directly in the DNS (ACL's and blackhole lists etc for example) and just open port 53 for TCP AND UDP for "any" - otherwise I'd recommend that you create an access list in the firewall(s) by creating an Alias and put all the networks that should be allowed to talk DNS in there (or the other way around if there are "too many" networks that should be allowed, ie: create a "blocklist" and put everybody that should NOT be able to talk DNS in there).You could create a different rule for your own, trusted servers (the exchange VM should go here) and allow these IP-addresses/networks to connect to ports 25:tcp, 53:tcp/udp etc.
If you have problems with attacks, make sure you log everything, if possible to an external syslog server, read these logfiles (with zmore|less, awk or similar so you can search in them and figure out patterns a bit and get a quick overview) and then create a blocklist. The rule with the block list could go first of all rules and just perform a silent drop (which is "cheaper" for your firewall(s) than to actually send a "reject"). Any attacker should be added to the blocklist asap. If your ISP provides this service (assuming you are not the ISP) you could ask them to fetch a copy of your blocklist via FTP or TFTP every now and then and have them add your blocks to their access lists in the distribution router or even better in their core network so you/they don't experience as much problems "all the way down to your link" which could cause dos etc.
Note that DNS uses both UDP and TCP on port 53.
On the topic of DNS I'd also like to recommend O'reillys book "DNS & BIND" (cricket liu et al). Also you can not over estimate the value of switching to a proper DNS software (such as BIND) if you are using any of the other (often "broken") variants available. For example Microsofts name server solution never has and still today does not "work", ie handle everything "in a correct way" according to protocols etc. Every week I see customers that has put something "illegal" in their MS box:es which results in:
A) they announce "illegal data" which might not work at al.
B) the DNS responses are recieved by "real" (ie: BIND) servers that just mark the data as "invalid" and the end users suffer.
Often the "DNS master" never even notices that the broken DNS service cases problems etc.Cheers,
/E -
Thanks to all for the input and help on this, learning as I go.
DNS was open, closed that, then after a week or so all traffic died down, back to normal.
~ Tom