Block WAN for packets with non-local destination, detecting spoofed addressses
-
Hi list,
I know this might be very fundamental things, I should already know. But my knowledge on pf is very limited.
It seems that someone behind our nat'ed firewall is causing DNS attacks on our ISP's name servers, and that is of course a major problem. I was advised to take two actions:
1. Look for IP spoofing in pf.
2. Block all traffic from the outside that hasn't a destination on the local network.Could any of you please tell me how to do these things the right way?
We are running pfSense 2.0.3.
Best regards and thank you,
Jon Theil Nielsen -
1. Look for IP spoofing in pf.
This means the source address of any packet coming into whatever interface on the firewall should match the interface subnet.
(but watch out for broadcast/multicast addresses)2. Block all traffic from the outside that hasn't a destination on the local network.
NAT already takes care of this, because no traffic will be for the internal IPs, only for the IP of the firewall. And only things in the NAT section will be forwarded.
So, most likely it's something from the first point. It will probably be packet going out of your firewall, to port 53/udp. Turn on logging to see what IP on your network is doing that, it is almost certainly infected and part of a botnet if your ISP is right.
-
SeventhSon,
Thank you for your answer. :)
At the end of the day, I simply had to turn of DNS forwarding in pfSense. According to the ISP, there were clear signs, that the DNS functionality in the firewall was hijacked. Taking this step immediately solved the problem.
Since I have only used pfSense for a couple of years and have a very limited knowledge on PF, I have run into new problems. Disabling the DNS forwarder has revealed some problems with the configuration of pfSense. For the rest of the (Windows and Mac) clients, I don't think there are problems, but on our server there are.
I have started a thread (http://forums.freebsd.org/showthread.php?p=221682#poststop) at the FreeBSB Forum, since the server is running that OS. I hope the guys over there can help me out. Otherwise, I will post the issues here too.
Regards,
Jon -
We already have rules to prevent spoofing in place.
What you probably have is overly permissive firewall rules that allow outsiders to reach your firewall on udp/53, and let it get used as a recursive resolver.
Fix your WAN rules, and you'll be fine.
On 2.1 you can change the binding/config of the forwarder so it only listens/responds to queries from the LAN, but that still doesn't make it any better if someone has WAN rules that let everything through. It may prevent DNS amplification attacks, but they can still get to far too many things.
-
jimp,
Thanks for your answer.
I modified the rule for port 53 on the WAN side (UDP/TCP), so only packets from the ISP,s name servers are allowed. Should I limit the destination to local addresses too? And would that be enough to make it safe to turn the DNS forwarder on again?
First of all, I don't want anybody to be able to attack the name servers via our connection. On the other hand, turning off DNS forwarding has introduced some severe problems for the server behind the firewall.Regards,
Jon -
Why are you allowing ANYTHING on the WAN to hit your firewall? It is not necessary. You need no rules on WAN to function as a DNS client to upstream servers.
pfSense is a stateful firewall. When a packet is allowed out (which it will be automatically) a state is created that allows the return traffic back in for that connection.
Unless you are running a public server behind your firewall, you need no rules on the WAN.
-
jimp,
Okay, my lack of knowledge on firewalling again… :-)
Actually, I do have a public server behind the firewall. It runs a number of services, that need to be public accessible, e.g. web server, ftp server, sshd server.
So would it work for me if I remove all rules from the WAN side that are not needed for anything else than NAT'ing to the server (actually, there are more than one server, but that's another story)?
Regards,
Jon -
In that case your only rules on WAN should be passing to the internal IPs of your servers and only for the ports/protocols required for those to function.
If you have any rules to "allow all" on WAN or anything else too permissive, it will cause you grief.
-
jimp,
I think it is perfect to clean up the firewall rules.
I have tried to read some other threads on the forum, so I don't have to ask too many silly questions.
Somehow, the setting Firewall->NAT->Outbound-> "Automatic outbound NAT rule generation (IPsec passthrough included)" was disabled, which I guess is not good. It is enabled now.
I have disabled most of the rules in Firewall->Rules->WAN. I just wonder if I should also disable those rules from the list, that are prefixed with "NAT"? Or is it okay just to keep the rules listed under Firewall->NAT->Port Forward?And again, if I follow your advice, would it be safe to turn on the DNS Forwarder again?
Thank you and regards,
Jon -
The rules that specify NAT are usually linked to port forwards, and are generally OK.
Outbound NAT wouldn't affect the firewall rules so that doesn't matter so much.
So long as your WAN rules aren't passing traffic into the firewall unnecessarily, it's safe to run the DNS Forwarder.
-
Okay, I actually removed those links, but it should be easy enough to reestablish them.
Apart from port 1723 which I'm uncertain about (for VPN passthrogh), there are no open ports from the WAN side except for the NAT rules.
I will enable the forwarder again. And hopefully everything will work as before - I'll do some testing. To be absolutely safe, I can ask the ISP to check the DNS traffic from our network.
Thank you again. :)
-
You can run your own test using a site such as http://openresolverproject.org/ or http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl
-
jimp,
I have spent some time cleaning up in the rules, enabling the forwarder both under System->Setup and Services->DNS Forwarder. After that, I tried with both links you provided.
It is not quite clear to me, if the two websites are using cached results. http://openresolverproject.org/ states that the IP is running an open resolver, while http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl in the first place stated the same. However, at the last site it was possible to request a new query. After a while, it returned "Date Checked: 2013-05-30 19:29:06, Status: closed".Can I check with nslookup or dig when the querying machine is behind the firewall and get any meaningful answer?
Of course, I could ask someone else to try from the outside, but I don't like to reveal my public IP address here.
Regards,
Jon -
I think the first one does give cached results, I'd trust the second test if it changed the results when you fixed your rules.
-
Thanks for all contributions!
Both the firewall and the servers behind it seem to be working as expected now.
At first, when I used tcpdump from the pfSense console I couldn't see any packages from the ISP's name servers going to my own servers. In my efforts for configure the servers to work without the DNS forwarder, I had edited the /etc/resolv.conf to pointing directly to the name servers. When I appended the LAN address of the firewall at the top of the list, everything was fine again.
I have tested if the firewall should still act as an open DNS resolver (http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl, and it doesn't.
Regards,
Jon