Evilcoder.org

Today Erwin Lansing froze the FreeBSD Ports tree in preparation for the 6.4 and 7.1 releases. That basically means that no one can commit to the ports tree without prior approval from the Ports Management team.

The freeze is done to give the machines in the build cluster the time to build packages for both releases, which can be included on the CD’s and uploaded to the various FTP-mirrors so that you (The end user) can use them when you install the versions.

Certain people will get a blanket from the Ports Management team, so that they can improve the current ports and document Security Vulnerabilities where needed, and ofcourse update the packages if that is required.

Stay Tuned

written by Remko \\ tags: 6.4, 7.1, Erwin Lansing, FreeBSD, freeze, ports, security, vulnerabilities

Today we learned that George Neville-Neil leaves the FreeBSD Security team due to lack of time. It’s sad that George leaves the team, but he leaves a lot of good work behind and he was a great asset to our Security Team. Therefor “Thank you for working with us George!”

written by Remko \\ tags: FreeBSD, FreeBSD Security Team, secteam, security

While most people think that Securing your DNS server is practically impossible, I want to give a few hints and tricks to make sure that it’s possible to mitigate problems from DNS to your local server.

This setup should actually be followed by everyone that cares about his DNS Server!

There are a few options to protect your DNS server as much as possible.

• Split your DNS servers. The internal networks is most likely to do remote queries, the external network probably only serves your internet zone’s. Why have them in one instance? Split the machines where possible, or create different views, so that the internal people can only recurse and the external people can only lookup the domains you host. (SPLIT-DNS)
• Add ACL’s and limit recursion; if you cannot do the above, you should try the best as possible to limit the amount of people that can use your DNS server to do remote lookups. Is it really necessary that joe-next-door uses your dns server to visit www.triplexdomain.com ? ISP’s are here to service these DNS queries for him

  an Example of an ACL in named:

  acl your-acl-name { 10.0.0.0/8; };

  This matches any host in the 10/8 network.

  Limiting recursion through the ACL

  Add the following to the options {}; statement in named.conf:

  recursion yes;
  allow-recursion { your-acl-name; };

  Do note the semicolons and the brackets!

• Use random query ports. Whilst in the past people had been using static ports for doing remote DNS queries, to make it easily go through firewalls, that’s no longer an option. Recently ISC and CERT announced advisory’s to address static-query-ports. It makes you very vulnerable to be spoofed, and could mean that secure.yourimportantbusiness.com suddenly points to my evil.notsoimportanthost.com so that I can trick your users into submitting their data on my machine, which I can then use to do very nasty things (like having a free holiday to the bahama’s, I like it already!).

  In this case one should point out a DNS server, and tell that it can do queries from port 53 and >1024, I have been using this setup for ages, and I do know that a lot of larger companies also have similiar rules in their external firewalls. This allows the DNS server to pick a lot of random ports to do queries from.

  If you use a recursive DNS (because you are an ISP); then consider using only SSH and BIND on the machine (or whatever product you use). The machine does not need to be firewalled at all then , as long as you disable any unused applications. One could ofcourse filter away the SSH login, but having a stateful filter before a large DNS is just asking for problems (thanks Bjoern and Doug for this information!).

• Use DNS-SEC where possible. Currently not many TLD’s support this, but if there is the possibility, you can add a security layer by using it. Ofcourse this does not prevent it forever, but it makes it again harder to do. And security is all about making the barrier too high to try (if the barrier is low, one will try, if it requires too much time or money, people will not do it that easily, though there is always someone that is willing to put in the required resources, keep that in mind).
• Always use the latest available version from your vendor where possible. It’s sometimes a pain in your royal behind’s to update the services you host. But do realise that mostly by running the latest (stable) release from your vendor, you can close many known holes. Yet it leaves you open for things not yet found ofcourse (but isn’t that always the case): do plan these kind of actions and make sure you test such a setup first, or keeping the “old” machine alive till you are confident that everything works. You do not want to explain to some high-ranking boss that you didn’t test, or that you cannot return to the old situation. (Something I learned to do is; install a new machine, and it’s applications. Test whether the basic things that you expect it to do; still work. Unplug (yes do not power off!) the old machine and plugin the new one. If you worked through it for XX days, then you can backup the old machine (make sure you test the backup before really turning off the machine!) and turn it off.
• Ofcourse managers and people around you will complain that it will require a lot of resources; properly planning things will demand tme and money etc. But you can easily counter that by telling your boss or manager that in case something does go wrong, the damage is most likely higher. Point at your risk-index numbers that you periodically create (right!?) to show what kind of risk is involved.

The above are ofcourse a couple of open-doors, though we (Security People) see enough in the real world to know that the above isn’t followed most of the time. Most bigger companies have the resources etc to properly do this, and some indeed use this to do the new setup, but many many many smaller companies are not using these kind of things at all, because it costs too much money. Please try to openly discuss these things with your company if you hit this. You are better off in the end if you properly discussed this, got a “no” anyway, and then things go wrong.

Hopefully the above helps a bit. I wrote this information stream based upon the latest CERT advisory for BIND, and having a few discussions here and there on the FreeBSD-Security Lists. Thanks Doug Barton, Bjoern A Zeeb to give me some thoughts about this (they might not be aware of this yet).

written by Remko \\ tags: bind, dns, FreeBSD, mitigate, named, security