Read how to test and update your system in this knowledgebase article.

All new VPS deployments we make as of December 3 will have the necessary updates to mitigate this vulnerability.

There are several options available since FreeBSD is a network enabled operating system. It has all the components available in it natively to act as a firewall or to firewall itself against external intrusions. In order to do it with the native support you’ll probably need to do a lot of reading, but isn’t securing your data worth the effort and time? A good, full-featured and robust firewall setup is detailed my Manuel Kasper over at his site and includes packet filtering, Network Address Translation, IP filtering and more. The complete write up is here (https://neon1.net/misc/firewall.html).
FreeBSD also comes with built-in, manually activated Packet Filtering, commonly called PF. It has been included in the kernel for some time and can be enabled by editing the rc.conf so that it contains: pf_enable=”YES” It must also have a ruleset to draw upon or it won’t activate. For more information on activating and creating a ruleset check out the FreeBSD HandBook pages on it.

http://www.freebsd.org/doc/en/books/handbook/firewalls-pf.html

There is also an open source application called pfSense which is a customized distribution of FreeBSD made specifically to be used as a firewall and router. It has been around for several years and has bolt-on extensions that can extend the capabilities of the distribution keeping the core software secure but allowing for flexibility. You can find out more about it at the project pages (http://www.pfsense.com/).

Nothing in life is 100% and that goes doubly so for network security. Just putting up a firewall is not a complete network security solution and you need to implement other security protocols to block against a wide variety of threats. In the end if you’re not a network security professional it might be in your best interest to consult one.

First off if you have a FreeBSD machine that you want to be the client you might look to using PPTP (if available) for the VPN connection. It’s by far one of the easiest ways available to get connected. I found a great walk through here at FreeBSD Diary (http://www.freebsddiary.org/pptp.php) with easy-to-read step-by-step instructions. You can also use OpenVPN which can be found here (http://www.openvpn.net/index.php/home.html).

Connecting a Windows machine to the FreeBSD gated VPN is a little more work. Probably the simplest of all solutions is OpenVPN again (http://www.openvpn.se/), install notes (http://www.openvpn.se/install.txt). I found a fairly good guide to doing all the setup on both ends right here which should get you up and running (http://www.ubergeek.co.uk/blog/2008/05/openvpn-freebsd-pf-windows-howto/).

One of the most complex solutions is the use of IPSec which requires a custom kernel be built. As that is an extremely involved process I will point you to a site with an excellent set of instructions and information over at the FreeBSD Handbook (http://www.freebsd.org/doc/en/books/handbook/ipsec.html). This is not for the faint of heart and requires a good amount of skill in order to make it work successfully. I suggest reading the document fully before attempting it, or looking into an easier way to do it (see above).

There have already been hundreds of articles  from different media outlets over the last few days about this.  Dan has clearly said that he has found a new DNS flaw although some people speculate that he is re-hashing previous security findings about the weakness in non-random udp source ports and TXIDs.  It won’t be until August that Dan reveals the details of this exploit that people can try to debunk his claim.

Paul Vixie, the primary author of BIND, wrote this on a mailing list recently, supporting Dan’s claims:

this is not a decade old problem.  it’s either as old as dns, or four months
old, depending on how you count.  somebody reminded me that i was one of the
earliest to ring an alarm bell on this, in a very weak, terrible 1995 paper:

http://www.usenix.org/publications/library/proceedings/security95/full_papers/vixie.txt

in 2002 i also attempted to demystify BCP38 since we all know that without
IP source address repudiability, no noncrypto UDP based protocol is safe:

http://www.icann.org/committees/security/sac004.txt

so, patrick and others, let me assure you, having been here all along and
having done what i could to secure the DNS QID for ~1.5 decades, i am aware
of the details of dan kaminsky’s attack, and it will be news on august 6,
and it justifies every bit of pain and panic involved in randomizing all UDP
source ports on DNS transactions between recursive and authority servers.

and let me take another opportunity to thank dan bernstein for coming up
with the idea of UDP source port randomization for DNS transactions.  we
know it works and we’re pushing hard to get it universally deployed.  (while
i’d rather have Secure DNS, the community could not possibly deploy that
fast enough, so we’re doing what we can while we can.)

so, you should fix it NOW NOW NOW!

We have already updated our caching DNS servers with the new patched code.  You should check to make sure that your servers are using caching DNS servers that have been patched with these latest updates.