Not pfSense related exactly, but thought many of you may be interested in this. The latest issue of BSD Magazine is available for free online. The topic of this issue is OpenBSD.
Archive for the ‘Industry’ Category
Did you ever think your router could become a bot? I guess the answer is no. However, there seems to be a botnet that can get control over linux based routers and modems that use MIPS hardwarearchitecture. For more details check out this link . This is somehow scary. Aren’t you happy you are using pfSense?
There’s a new threat in the wild where a single infected machine in your network can harm all other dhcp clients on the same net: A trojan answering to dhcp-requests.
If that trojan is answering faster than your real dhcp-server it will assign some malicious dns-servers to the client that sent out the request. This is making phishing pretty easy but could also lead to the installation of faked updates.
You can find some more information about that trojan at the symantec page.
A way to prevent this using pfsense is to use a firewallrule on your internal networkinterface that is blocking all outbound tcp/udp port 53 (DNS) connections to any destination. Make sure your internal dns-server, that is manually configured and not affected by this dhcp attack, has a pass rule on top of this block rule or if you use the pfsense as dns-forwarder create a rule that grants access to the pfsense ip on port 53 tcp/udp. This way a client with faked dns-server will not be able to resolve dns anymore which will be noticed pretty soon instead of possibly using the malicious dns servers without noticing it.
A licensing server glitch caused thousands of SonicWALL firewalls to become unauthorized and disabled all protection.
“It is being reported that firewall services have stopped and that spam, viruses, and other bad things are flowing in without a hitch.” – SANS ISC
It appears everything stopped functioning – firewalling, VPN, you name it. Obviously not such a good idea to have your network protected by DRM that can so easily go haywire and disable all protection!
Frustrates? I’d use far stronger words if I were a customer.
WPA2 when using TKIP is also affected.
Running a VPN on top of your wireless encryption can offer additional protection, and you may want to consider such a deployment regardless of the wireless encryption deployed in your network. Whether pfSense is your AP, or your APs connect to it, it can provide VPN services to internal users on your wireless network, and you can restrict all traffic coming in from your wireless network to only access the VPN. Then after successfully authenticating to the VPN, users can access your internal network and/or the Internet.
Edit: SANS has a good webcast on this topic for those interested in details.
If you manage any network, chances are you have at least one device managed via a web interface. If you manage a corporate environment, it may be up into the dozens, hundreds, or thousands. While web based administration is desirable for a number of reasons such as cross-platform administration capabilities, it also has some unique security risks.
Every web managed device has had a few issues over the years, and pfSense and m0n0wall haven’t been exempt. There are also issues inherent in web managed systems that the systems themselves have little or no control over. The following provides some recommendations on how to securely manage any web-administered device, not specific to pfSense. You should consider these things in the management practices of every device on your network controlled via a web interface.
Keep up to date
Vulnerabilities will inevitably be found on occasion in your web managed devices. We fixed some issues in pfSense prior to 1.2 release, as soon as we were aware of them. Most were minor, though one that was common to m0n0wall, DD-WRT and several other similar distributions allowed cross-site request forgery (CSRF) on the DHCP leases page. This allowed anyone on a local segment with the DHCP server enabled to inject things into the hostname of the DHCP request that would then be displayed unsanitized on the DHCP leases screen. This allowed someone on a locally connected subnet to do anything to your firewall, if you logged into the management interface and viewed the DHCP leases page. There is an exploit out for this now, and a paper covering this kind of issue in web administered devices. If your internal network contains untrusted users, it is important to be running 1.2 release! Note this is only possible for machines connected to an interface with the DHCP server enabled, it isn’t exploitable by anyone outside your network.
Restrict management access
More serious vulnerabilities can allow unauthenticated users with access to the management interface to do bad things. To proactively protect your network from issues like this that may be discovered in the future, restrict access to the management interface as much as possible. First, never open any web management interface’s port to the entire Internet! If you require access from the WAN side, be as restrictive as possible with source IPs or networks. Using a VPN connection and accessing the admin interface by internal IP over VPN is a more secure solution for remote administration.
You should also restrict management access on your internal network in many environments. If you’re administering a small home network, you probably don’t care. If it’s a network with dozens, hundreds, or thousands of devices, restricting access internally is strongly recommended. There is a howto on the doc site describing how restrict management access in pfSense. You should investigate similar controls on your other web managed devices.
Don’t browse the Internet with the same browser you use for administration
If you are authenticated to a web managed device in the same browser you are using to access the Internet, there are several possibilities for persons with nefarious intent to exploit that access. The safest thing is to never browse the Internet from the browser you use for administration. If you use Firefox for Internet browsing, use Opera, Internet Explorer, Safari or some other browser for administration. pfSense works with all those mentioned browsers, though there are a few cosmetic issues in browsers other than Firefox, they don’t affect your ability to manage the device. As an aside, we welcome patches to fix those cosmetic issues in other browsers. We aren’t masochistic enough to care to fix them. ;)
Use a dedicated system not connected to the Internet for administration
You can take the above one step further by using a dedicated machine or virtual machine for administration of your web managed devices that does not have any access to the Internet. The best means of ensuring it doesn’t have Internet access is to assign the management PC a static IP or DHCP reservation and reject Internet-bound traffic from that IP at your perimeter firewall. This is an extreme step in most environments, but is something to consider.
Amazon has posted my review of Network Administration with FreeBSD from Packt Publishing. It may be of interest to those of you working with stock FreeBSD systems. While I wouldn’t call it a great book, as my review indicates, it’s absolutely proven useful. I’ve picked it up on a few occasions for reference purposes.
For those new to FreeBSD and wanting to learn more, the above is not intended as a book for beginners. For anyone new to FreeBSD, I recommend Absolute FreeBSD. I have not yet had a chance to read the second edition, but recommend it because the first edition was great, Michael Lucus is an excellent writer, and it has gotten exceptional reviews from people whose reviews I always find spot on, like Richard Bejtlich.
None of this is really relevant to pfSense, unless you want to become a developer. We hide all the details of FreeBSD so you don’t need to know these things. But if you’re interested in deploying FreeBSD in other uses, these may be of use.
If you run your own DNS server and haven’t patched yet – now would be the time to do so. The details of the previously mentioned vulnerability were inadvertently made publicly available earlier today.
Our previous assertion that dnsmasq in pfSense is not vulnerable was correct. We will be putting out a version with the updated dnsmasq, however this is just to protect from the possibility of a different attack in the future. With this particular issue there is no immediate need to update caching-only DNS servers including pfSense.
So what needs to be patched?
The server that issues recursive queries to your DNS requests. What server this is varies depending on your configuration. I’ll group into two categories.
pfSense DNS Forwarder Users
For those who use the DNS forwarder on pfSense for all internal DNS, the servers that need to be patched are your ISP’s. For dynamic IP connections, in a default configuration the servers assigned by your ISP will be used for recursive lookups. You can override this by entering servers on the System -> General Setup page and unchecking the “Allow DNS server list to be overridden by DHCP/PPP on WAN” box.
Users of Internal DNS Servers
You will need to make sure your internal DNS server is patched.
How can I tell if I’m vulnerable?
Visit DoxPara and click the “Check my DNS” button.
Fixing the Issue Without Relying on your ISP
You can easily fix this without relying on your ISP applying patches by using OpenDNS, a free DNS service that was never vulnerable to this issue in the first place. To use OpenDNS, just enter 220.127.116.11 and 18.104.22.168 for your DNS servers in the General Setup page, and uncheck the “Allow DNS server list to be overridden by DHCP/PPP on WAN” box. Click Save on that page, and re-test. You will see you are no longer vulnerable.
pfSense Will Not Make Your Patched Servers Vulnerable
Unlike numerous other firewall and NAT products including some big name commercial vendors, pfSense will not un-randomize the source ports on NATed traffic leaving you vulnerable. If you are using NAT on anything other than pfSense, make sure that device isn’t defeating the purpose of the DNS server patches by improperly rewriting. The DoxPara test will determine that.
Recently came across a number of great reasons why you should not be using FTP.
Take a look at let me know what you think: http://stevenf.com/archive/dont-use-ftp.php
While the author of dnsmasq does not feel it is susceptible to the recent DNS vulnerability “panic”, he did release an updated RC version including query source port randomization. It appears dnsmasq is not vulnerable because it does not do any recursive queries – it relies entirely upon your ISP’s DNS servers or internal ones you have defined. Hence it appears that as long as your ISP isn’t vulnerable, you aren’t vulnerable. If you have instead defined internal DNS servers, they are the ones that will need to be patched.
The DNS server package in pfSense uses djbdns, which is the only major DNS server package that was not vulnerable.
We feel it’s safe to say this probably does not affect dnsmasq in pfSense – but we can’t say for sure until the details are released at Black Hat in August. This fix is still a good one to deploy because it makes other potential cache poisoning vectors much more difficult.
Please help us test this new version of dnsmasq. This is for 1.2-release systems only, those using 1.2.1 or 1.3 snapshots can update by installing a new full update from the snapshot server. We have been testing it and have not found any issues.
To install the updated dnsmasq on pfSense 1.2 full installs:
- Go to a command prompt (SSH or Diagnostics -> Command)
- Run the following commands one by one.
mv /usr/local/sbin/dnsmasq /root/
fetch -o /usr/local/sbin http://cvs.pfsense.org/~sullrich/dnsmasq
chmod +x /usr/local/sbin/dnsmasq
At that point you will be running the updated dnsmasq and everything should be working properly.
Thanks to dnsmasq author
Thanks much to Simon Kelley for making a dnsmasq update available so quickly, and promptly replying to our inquiry!
Updated release information
Once this fix has been more widely tested, we will release pfSense 1.2a with only this change. Based on the information we have available, this currently does not warrant a wrecklessly quick fix with the potential cost of stability. All things at this time point to this specific issue being applicable only to servers that issue recursive queries, and hence not dnsmasq.