Thursday 29 November 2007

Cisco firewall dns packet size setting

I recently noticed that our cisco firewalls were denying dns packets being returned which are greater than 512 bytes in size.

On investigation this is the default setting on Cisco PIX and ASA firewalls and used to be correct as per the RFC for udp dns packet sizes. Over this size TCP packets used to be used. Due to the overhead of using TCP and various security issues it appears eDNS was invented to allow larger UDP packet sizes.

From what I can determine there is a flag passed when a dns server requests a lookup indicating whether it accepts Edns and its maximum packet size. If your firewall is configured to a different value there will clearly be issues as it will deny the valid packet that is returned.

BIND appears to cope with this situation by reverting back to a packet size of 512 if the initial query fails. I've not found out what Windows does if this happens but you would hope it does the same.

A bit of research shows this feature was implemented in Windows 2003 with a default edns packet size limit of 1280 and in Bind 9 with a default packet size of 4096.

So if you are using these dns servers you may want to adjust your firewall settings accordingly or research what your dns server does and what its default value is.
BIND 9 uses EDNS0 (RFC2671) to advertise its receive buffer size. It also sets DO EDNS flag bit in queries to indicate that it wishes to receive DNSSEC responses. Most older servers that do not support EDNS0, including prior versions of BIND, will send a FORMERR or NOTIMP response to these queries. When this happens, BIND 9 will automatically retry the query withoutEDNS0.

You can configure both dns servers not to use edns and you can configure the maximum packet size but I guess the easiest option is to configure your firewall correctly.

Related articles

http://www.isc.org/index.pl?/sw/bind/bind-security.php
http://homepages.tesco.net/J.deBoynePollard/FGA/dns-edns0-and-firewalls.html
http://www.isc.org/index.pl?/sw/bind/view/?release=9.4.1-P1
http://technet2.microsoft.com/windowsserver/en/library/099d4168-4ac1-441d-81b7-0f3f4909fbd41033.mspx?mfr=true
http://northeasttech.com/classroom/courses/2278/Student/Appendix/2278B_XA.pdf

Friday 23 November 2007

Fedora Core 8 Network Install (no dvd available)

Since Redhat Fedora Core 8 (FC8) only appears to come on DVD and not on CD any more its a bit of a problem to install it on older systems with no DVD.

You can either install directly over the internet or download the iso and serve the files locally via your own http or ftp server.

Using download.fedora.redhat.com (or a mirror)

Creating your own server (skip if you are going to install over the internet)

Download the full dvd iso.

Then either burn it to a dvd and configure your web server/ftp server to allow access to the dvd or copy the files off the dvd to your web server/dvd server. Alternatively extract the files directly from the iso to a directory on your web server/ftp server (I used winrar on windows and then used windows personal web server to serve the files).

Create a boot disk

Download the Fedora Core 8 Rescue Disk iso image from (/pub/fedora/linux/releases/8/Fedora/i386/iso) and burn this on to a CD.

Boot and Install

Boot the server where you want to install FC8 from the Rescue Disk.

When it boots choose Install or upgrade an existing system from the menu.

Select the language and keyboard type from the menu.

You can then choose to install from Local CD/DVD, Hard drive, NFS directory, FTP or HTTP

Choose HTTP or FTP as appropriate and fill in the details.

In my case I used Http so I then input just the ip address of my web server and the directory containing the unpacked iso image. If you are using a service over the internet then you need to target the 'os' directory (/pub/fedora/linux/releases/8/Fedora/i386/os).

The install should then detect the 'disk' and offer the option to check the media (say no!). Proceed as normal with the install.

Notes:

You can also use boot.iso (minimal boot) or diskboot.img (usb stick) to boot and start the install (These can be found in fedora/linux/releases/8/Fedora/i386/os/images on any mirror.) but its always worth creating the rescue disk just in case you ever need to rescue your server. Leave one next to the server!

Saturday 17 November 2007

How to get Cisco VPN working on Vodafone

If you are using vodafone mobile broadband or dialing up via your mobile you may wish to connect to the office via vpn. If this is using a firewall such as the Cisco ASA devices you may find it connects but then you can not do anything.

Firstly you need to ensure that NAT-T is enabled in your IKE global parameters. Its in the VPN tab on ASDM under IKE - Global parameters.

Next you must ensure NAT-T is enabled in your IPSEC rules for your dynamic vpn connections. Its on the IPSec - IPSec Rules tab, and you need to tick the NAT-T box for each of your dynamic VPN rules.

You should now be able to connect and access your services via Vodafone.

If you notice that you can now only access things at the office and no other sites (such as google for instance) then you are probably sending all your internet traffic to the office instead of just that which is relevant to the office.

So you need to set up a tunnel rule.

The best way is to create a new Group Policy on the firewall (or edit the one you have already set up for remote connections). When you create the new Group Policy leave everything set to inherit except for Split Tunnel Policy and Split Tunnel Network List on the Client Configuration tab.

Set Split Tunnel Policy to 'Tunnel Network List Below'.

Then click on the Manage button below that.

You should get a pop up window called ACL Manager with no entries defined.

Click on Add, Select Add ACL, when prompted for ACL Name, enter a name for your ACL such as SplitTunnelList. Click on the new ACL you added then click on Add again and this time select Add ACE.

Enter the IP Address of your internal network, in this example its 192.168.2.0 and then enter the network mask, in this case 255.255.255.0. Ensure Permit is ticked.

Finally select your remote access Tunnel Group and assign it the new Group Policy. Save all the settings and reconnect via vpn. Your office traffic should still work but you should also be able to surf the internet directly via your own connection.

Basic - How DNS Works

In this article I will try and explain the basics of DNS, what it is, what you use it for and how important it is.

DNS is basically a set of records that allow a name you enter in a browser such as www.ippatrol.co.uk to be converted into a numeric ip address that a computer can understand and use to connect to the actual web server.

You can in many cases just use the ip address but that would be hard to remember and if it changes you will be lost so we use dns to make things easier to remember.

DNS is comprised of a number of different record types some of which I explain below.

An 'A' record is something like www, added to your domain (ippatrol.co.uk) it gives an easy to remember url www.ippatrol.co.uk. When you enter this in your browser your pc use dns to translate the 'A' record to the ip address of the web server server, requests the page and displays it.

An 'MX' record is an incoming mail server record, you normally have more than one, each has a priority. Mail will go to the lowest priority if this fails it will try the others in order. So when you send an email your isps mail server finds the mx record of the receipients mail server, gets the ip address and then connects to that server to send the email.

a 'CNAME' is a conical name and basically just points at another name (A record), it can make maintenance easier as you then may only need to change one 'A' record but I generally don't use them.

So instead of defining ftp as an 'A' record you may make ftp a cname pointing to say www so when its looked up it looks at the record for ftp, finds its a cname, looks up www and gets the ip address of the server.

A lot goes on in the background to look up a dns entry. First we have to query the root name servers (the heart of the internet), to find out which top level domain servers will help to answer your lookup.

so for instance to lookup www.ippatrol.co.uk we need to know who provides uk responses

host -t ns -d uk

;; ANSWER SECTION:
co.uk. 170706 IN NS ns6.nic.uk.
co.uk. 170706 IN NS ns7.nic.uk.
co.uk. 170706 IN NS nsa.nic.uk.
co.uk. 170706 IN NS nsb.nic.uk.
co.uk. 170706 IN NS nsc.nic.uk.
co.uk. 170706 IN NS nsd.nic.uk.
co.uk. 170706 IN NS ns1.nic.uk.
co.uk. 170706 IN NS ns2.nic.uk.
co.uk. 170706 IN NS ns3.nic.uk.
co.uk. 170706 IN NS ns4.nic.uk.
co.uk. 170706 IN NS ns5.nic.uk.

then we ask one of those servers for the domain's (ippatrol.co.uk) dns servers.

host -t ns -d ippatrol.co.uk ns6.nic.uk.

ippatrol.co.uk. 172800 IN NS ns1.dcl.co.uk.
ippatrol.co.uk. 172800 IN NS ns2.dcl.co.uk.
ippatrol.co.uk. 172800 IN NS ns3.dcl.co.uk.

In this case there are 3.

Once you have the name servers you can then lookup the record you want

host www.ippatrol.co.uk ns2.dcl.co.uk.
Using domain server:
Name: ns2.dcl.co.uk.
Address: 85.13.195.78#53
Aliases:

www.ippatrol.co.uk has address 81.201.137.96

Its actually a bit more involved than that but thats the basic idea.

You could always lookup a few domains on somewhere like dnsreport.com to see how they are set up.

You should try and ensure your dns is hosted by a reliable dns host. Unfortunately most people just rely on the free service provided by their domain registrar, spend thousands on their web site only to find the dns service is unreliable and people can't find their web site.

Be aware DNS is cached (to speed up the internet) in your browser, on your pc and on your isps's dns servers. So you may be able to access your site, but your dns servers may be down and other visitors may not be able to access it. You will only see the problem when your cache expires. So check your dns out somewhere like checkdns.net if some reports a problem.

Your dns provider should provide at least 2 dns servers (in case one fails). They should be located in different data centers so that an outage at one place does not affect your dns service.

Finally they should really be located in the country where your servers are or where your customers are, beware some dns providers who appear to be located in the UK are for instance located in North America.

A simple traceroute to their name servers should clarify the situation. The best thing to do is ask your potential dns provider all these questions.

Before registering a domain check out their dns service and also check how much it costs to transfer away from the registrar if you need to. It should be possible to do everything yourself from a control panel without their intervention. If they don't allow this or charge you for releasing your domain then avoid them like the plague.

Finally once you have configured your dns check its correct using a free service like dnsreport.com and do this every time you update it. To do a one off test of your dns, web site and mx records try checkdns.net.

Once everything is working signup with ipPatrol (www.ippatrol.co.uk) and get your web site monitored 24x7 with instant alerts via email and sms so you know when it stops working and can get it fixed before your customers notice or you start losing business. Don't rely on your isp to do this, most don't do effective monitoring (they just ping the server) and even less will tell if a problem has occurred.