Tuesday, July 13, 2010

Blogs for Network Geeks

AGGREGATORS / LISTS



GENERAL NETWORKING



CERTIFICATION / STUDY


Vendor Blogs, Feeds, and Tweets for Network Geeks

This is a list of vendors who service the networking industry in areas of wireless, routing, switching, VoIP, security, or management.

Saturday, June 12, 2010

Securing Debian Configuration checklist



  • Limit physical access and booting capabilities


    • Enable BIOS password


    • Disable floppy booting


    • Set a LILO or GRUB password (/etc/lilo.conf or
      /boot/grub/menu.lst, respectively); check that the LILO or GRUB
      configuration file is read-protected.


    • Disallow MBR floppy booting back door by overwriting the MBR (maybe not?)




  • Partitioning


    • Separate user-writable data, non-system data, and rapidly changing run-time
      data to their own partitions


    • Set nosuid,noexec,nodev mount options in /etc/fstab
      on ext2 partitions such as /tmp




  • Password hygiene and login security


    • Set a good root password


    • Enable password shadowing and MD5


    • Install and use PAM


      • Add MD5 support to PAM and make sure that (generally speaking) entries in
        /etc/pam.d/ files which grant access to the machine have the
        second field in the pam.d file set to "requisite" or
        "required".


      • Tweak /etc/pam.d/login so as to only permit local root logins.


      • Also mark authorized tty:s in /etc/security/access.conf and
        generally set up this file to limit root logins as much as possible.


      • Add pam_limits.so if you want to set per-user limits


      • Tweak /etc/pam.d/passwd: set minimum length of passwords higher (6
        characters maybe) and enable md5


      • Add group wheel to /etc/group if desired; add pam_wheel.so
        group=wheel entry to /etc/pam.d/su


      • For custom per-user controls, use pam_listfile.so entries where appropriate


      • Have an /etc/pam.d/other file and set it up with tight security




    • Set up limits in /etc/security/limits.conf (note that
      /etc/limits is not used if you are using PAM)


    • Tighten up /etc/login.defs; also, if you enabled MD5 and/or PAM,
      make sure you make the corresponding changes here, too


    • Disable root ftp access in /etc/ftpusers


    • Disable network root login; use su(1) or sudo(1).
      (consider installing sudo)


    • Use PAM to enforce additional constraints on logins?




  • Other local security issues


    • Kernel tweaks


    • Kernel patches


    • Tighten up logfile permissions (/var/log/{last,fail}log, Apache
      logs)


    • Verify that setuid checking is enabled in /etc/checksecurity.conf


    • Consider making some log files append-only and configuration files immutable
      using chattr (ext2 filesystems only)


    • Set up file integrity . Install debsums


    • Consider replacing locate with slocate


    • Log everything to a local printer?



    • Burn your configuration on a bootable CD and boot off that?


    • Disable kernel modules?




  • Limit network access


    • Install and configure ssh (suggest PermitRootLogin No in
      /etc/ssh, PermitEmptyPasswords No; note other suggestions in text
      also)


    • Consider disabling or removing in.telnetd


    • Generally, disable gratuitous services in /etc/inetd.conf using
      update-inetd --disable (or disable inetd altogether, or use a
      replacement such as xinetd or rlinetd)


    • Disable other gratuitous network services; mail, ftp, DNS, www etc should not
      be running if you do not need them and monitor them regularly.


    • For those services which you do need, do not just use the most common programs,
      look for more secure versions shipped with Debian (or from other sources).
      Whatever you end up running, make sure you understand the risks.


    • Set up chroot jails for outside users and daemons.


    • Configure firewall and tcpwrappers (i.e. hosts_access(5)); note
      trick for /etc/hosts.deny in text


    • If you run ftp, set up your ftpd server to always run chrooted to the user's
      home directory


    • If you run X, disable xhost authentication and go with ssh instead; better yet,
      disable remote X if you can (add -nolisten tcp to the X command line and turn
      off XDMCP in /etc/X11/xdm/xdm-config by setting the requestPort to
      0)


    • Disable outside access to printers


    • Tunnel any IMAP or POP sessions through SSL or ssh; install stunnel if you want
      to provide this service to remote mail users


    • Set up a loghost and configure other machines to send logs to this host
      (/etc/syslog.conf)


    • Secure BIND, Sendmail, and other complex daemons (run in a chroot jail; run as
      a non-root pseudo-user)


    • Install snort or a similar logging tool.


    • Do without NIS and RPC if you can (disable portmap).





  • Policy issues


    • Educate users about the whys and hows of your policies. When you have
      prohibited something which is regularly available on other systems, provide
      documentation which explains how to accomplish similar results using other,
      more secure means.


    • Prohibit use of protocols which use cleartext passwords (telnet, rsh and
      friends; ftp, imap, http, ...).


    • Prohibit programs which use SVGAlib.


    • Use disk quotas.




  • Keep informed about security issues


    • Subscribe to security mailing lists


    • Subscribe to security updates -- add to /etc/apt/sources.list an
      entry (or entries) for http://security.debian.org/debian-security


    • Also remember to periodically run apt-get update ; apt-get upgrade
      (perhaps install as a cron job?).




Sunday, May 23, 2010

Layer by Layer Troubleshooting with a Cisco Router

Every network admin is going to have trouble with network links on a Cisco router, at one point or another. The best way to troubleshoot any networking issues is to use the OSI model and go layer by layer. In my article How to use the OSI Model to Troubleshoot Networks, we talked about the different troubleshooting approaches and how to use them to troubleshoot your network, in general. In this article, you will find out how to use the OSI model to troubleshoot, bottom up, using a Cisco router.


OSI Model - Bottom Up Troubleshooting


If you will recall, the OSI model starts with the physical layer (layer 1) and goes up to layer 7 (application). When troubleshooting with a Cisco router, much of your time will be spent working in layers 1-3. They are:



  • Layer 3 - Network

  • Layer 2 - Data Link

  • Layer 1 - Physical


Because these layers build on each other, Layer 1 is most critical, without layer 1, layer 2 will not function. Without layer 1 & 2, layer 3 will not function, and so on. For this reason, I start troubleshooting at layer 1, physical, and move on up from there.


Router Troubleshooting at OSI Layer 1 & 2 - Physical & Data link


Remember, if Layer 1 isn't up, nothing else will work so make sure you start here. Examples of layer 1 are your T1 circuit or your Ethernet cable - physical connectivity. I usually troubleshoot layer 1 and layer 2 in union because they are so closely paired. Examples of layer 2 - data link - are your line protocol (such as Ethernet, ATM, 802.11, PPP, frame-relay, HDLC, or PPP).


To troubleshoot at these layers, the first thing I would do on your router is a show interface. Here is an example of a LAN Gigabit Ethernet circuit:


Router# show interface
GigabitEthernet0/0 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is 0015.2b46.5000 (bia 0015.2b46.5000)
Description: LAN Connection to Data center
Internet address is 10.20.100.1/16
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, link type is autonegotiation, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/2/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 750000 kilobits/sec
5 minute input rate 3218000 bits/sec, 1715 packets/sec
5 minute output rate 1390000 bits/sec, 2129 packets/sec
1416888620 packets input, 15402720 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 1556005 multicast, 0 pause input
0 input packets with dribble condition detected
1666663097 packets output, 573841802 bytes, 0 underruns
19 output errors, 0 collisions, 3 interface resets
0 babbles, 0 late collision, 0 deferred
19 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

Here is what a WAN T1or T3 circuit might look like:


Routerl# show interface serial 3/0
Serial3/0 is up, line protocol is up
Hardware is DSXPNM Serial
Description: Sprint T3
Internet address is 10.2.100.2/30
MTU 4470 bytes, BW 9000 Kbit, DLY 200 usec,
reliability 255/255, txload 77/255, rxload 26/255
Encapsulation HDLC, crc 16, loopback not set
Keepalive set (10 sec)
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 18394
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 927000 bits/sec, 1914 packets/sec
5 minute output rate 2752000 bits/sec, 1504 packets/sec
1560997932 packets input, 3254680247 bytes, 0 no buffer
Received 255480 broadcasts, 1 runts, 1 giants, 0 throttles
1567 input errors, 1567 CRC, 976 frame, 496 overrun, 0 ignored, 908 abort
1303636803 packets output, 3737276508 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 output buffer failures, 0 output buffers swapped out
1 carrier transitions
DSU mode 1, bandwidth 9000, real bandwidth 9000, scramble 0

Here is the quick version:


Router# show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 10.20.100.1 YES NVRAM up up
Serial3/0 10.2.100.2 YES NVRAM up up

Here is what you look for:



  • Is the interface UP?

  • Is the line protocol UP?

  • If both the interface and line protocol are NOT up, your connection is never going to work.

  • To resolve a line down, I look at the cable or the keepalives

  • To resolve a line protocol down, check to make sure that the protocols match on each side of the connection(notice the "line protocol" on each of the interfaces above).

  • Are you taking input, CRC, framing, or other errors on the line (notice how the serial interface above does show errors)? If so, check your cable or contact your provider.


In general, verify that you have a good cable on each side, verify that line protocols match, and that clocking settings are correct.


If this is an Ethernet connection, is there a link light on the switch?


If this is a serial connection, do you have an external CSU/DSU? If it is an external CSU, check that the Carrier Detect (CD) light & data terminal ready (DTR) lights are on. If not, contact your provider. This also applies if you have an internal Cisco WIC CSU card. If that is the case, take a look at this Cisco link on understanding the lights on that card.


You can, of course, use the Cisco IOS test commands to test your network interfaces with internal staff and with your telecommunications providers.


Do not proceed to upper level layers until your Physical interface on the router shows as being UP and your line protocol is UP. Until then, don't worry about IP addressing, pinging, access-lists or anything like that.


Router Troubleshooting at OSI Layer 3 - Network


Once you have Layers 1 & 2 working (your show interface command shows the line is "UP & UP", it is time to move on to layer 3 - the OSI Network layer. The easiest thing to do here to see if layer 3 is working is to ping the remote side of the LAN or WAN link from this router. Make sure you ping as close as possible to the router you are trying to communication with - from one side across to the other side.


Here are examples of successful & failed pings:


Router# ping 10.2.100.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.100.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Router#
Router#
Router#
Router#
Router# ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Router#

The easiest way to check the status of Layer 3 - the network layer - is to do a show ip interface brief, as I did above. Here is an example:


Router# show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 10.20.100.1 YES NVRAM up up
Serial3/0 10.2.100.2 YES NVRAM up up

Notice the IP addressing on each of these interface. Also do a show running-config, like this (you can even specify an interface, like this):


Router# show running-config int serial3/0
Building configuration...

Current configuration : 225 bytes
!
interface Serial3/0
description Sprint T3
bandwidth 9000
ip address 10.2.100.2 255.255.255.252
no ip proxy-arp
no ip mroute-cache
dsu mode 1
dsu bandwidth 9000
no cdp enable
end

Router#

I would recommend taking this interface configuration and comparing it, side by side, with the remote WAN connection to ensure they are the same. Ask yourself questions like:



  • Are these interfaces on the same IP network?

  • Do these interfaces have the same subnet mask?

  • Are there any access-lists (ACL) that are blocking your traffic?

  • Can you remove all optional IP features to make sure that the basic configuration works before adding additional features that could be causing trouble?


Here is an example. Look at the two interfaces below. What is the real problem, causing these two to not communicate?


Router 1


interface Serial3/0 description Sprint T3 - TO ROUTER 2 bandwidth 9000 ip address 10.2.100.2 255.255.255.252


Router 2


interface Serial3/0 description Sprint T3 - TO ROUTER 1 bandwidth 1500 ip address 10.2.100.5 255.255.255.252


No, there is no problem with the bandwidth statement. Bandwidth statements are only used as comments and by routing protocols to select the best route. The real problem here is that the second router's serial interface is not on the same IP subnet as router #1. Even though they have the same subnet, the 10.2.100.5 IP address will never be able to communicate to the 10.2.100.2 IP address because they are on different networks but directly connected.


Let's say that you are now able to ping across the link, from one side to another. While that is a great sign, it doesn't always mean that everything is "fixed". You still may not be able to communicate from a client on the LAN of one router, to a client on the LAN of another router, due to things like improperly configured IP routing protocols.


For one LAN to communicate to another LAN, through routers (through a WAN, usually), you MUST have either static routes or dynamic routes configured. To ensure you have a route configured for the network you are trying to reach, do:


Router# show ip routes


and look at


Router# show ip protocols


For troubleshooting layers 3, all the way up, look at the output of this command:


Router# show ip interfaces

GigabitEthernet0/0 is up, line protocol is up
Internet address is 10.20.100.1/16
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.10
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is disabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is disabled
IP Flow switching is enabled
IP CEF switching is enabled
IP CEF Flow Fast switching turbo vector
IP multicast fast switching is disabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast, Flow cache, CEF, Subint Flow
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Policy routing is disabled
Network address translation is enabled, interface in domain inside
WCCP Redirect outbound is disabled
WCCP Redirect inbound is disabled
WCCP Redirect exclude is disabled
BGP Policy Mapping is disabled

Router Troubleshooting at OSI Layers 4 - 7


Now, let's say that you have made it to the point where you can ping from LAN to LAN, through your WAN. Congratulations - that is a very good sign. If you are still having trouble, it must be in OSI Layers4-7. Here are those layers listed out and possible issues you might experience in each layer:



  • Layer 4 - Transport - in the transport layer are TCP and UDP - you could be have an ACL or QoS feature blocking or slowing this traffic. Your TCP traffic could also be fragmented to the point that it could not be reassembled. Another option is that you may not be receiving an ACK back from your traffic that was successfully sent.

  • Layer 5 - Session - in the session layer are protocols like SQL, NFS, SMB, or RPC - you could be taking errors on any one of these session protocols. I would recommend using a protocol analyzer like Wireshark to analyze your session data.

  • Layer 6 - Presentation - in the Presentation layer are data encryption, compression, and formatting - your VPN tunnel could be failing or perhaps you are sending one type of data (like a MPEG) and the receiver is trying to view it as a WMV file.

  • Layer 7 - Application - in the Application layer are, of course, your applications like FTP, HTTP, SCP, TFTP, TELNET, SSH, and more - you could be trying to connect to a telnet server with the SSH protocol, for example.

  • Layer 8 - End User - the standing joke is that "Layer 8" is the user - the user could be just mistyping their username or password or you, the network admin, could have been troubleshooting the wrong IP address all along.


Summary


In summary, using the OSI model to troubleshoot connectivity issues is the fastest and most efficient way to troubleshoot any network issue. Even if someone calls you to work on a Windows share problem, all of the same principles in this article apply to that troublesooting process. So remember, the next time you work on a network issue - remember the OSI model and how to use the bottom-up approach to troubleshooting! It could same you a while lot of time!

Monday, May 17, 2010

HOWTO: Setting up QEMU on Ubuntu with TUN/TAP and NAT

Step 1) Compile and setup of Qemu and KQemu
Step 2) Installation of GuestOS [ Windows 98se in this example ]
Step 3) Setup of Tun/Tap network interface on host and guest OS.
Step 4) NAT setup to allow guestOS access to the internet.

*note: KQEMU is the QEMU Accelorator

Brief Description:
QEMU is an Open-Source Emulator that emulates x86 arch as well as several others.... allowing for guestOS's to be installed inside the host OS.
QEMU is available for Linux, Mac, and Windows. We'll be covering the Linux Package in this HowTo.
For more information on QEMU visit the projectpage @ http://fabrice.bellard.free.fr/qemu/

What you'll need:
+ QEMU source tarball from http://fabrice.bellard.free.fr/qemu/
+ KQEMU binary tarball from http://fabrice.bellard.free.fr/qemu/
+ linux-headers package
+ IPTables ( should already be installed ) package
+ libsdl1.2-dev package
+ Tun/Tap package
+ uml-utilities package
+ windows98 install cd and valid windows98 serial.
+ GCC-3.4 package

Ok, so this is the first HowTo i've wrote in quite a long time. First for ubuntu, and Qemu..


################################################## ##############
[ Step 1 ] - Compilation and Installation of KQEMU and QEMU

Outlined here is the steps taken to compile and setup Qemu and Kernel Module KQemu

A) Download the latest source tarball of QEMU from http://fabrice.bellard.free.fr/qemu/download.html current version is 0.8.1
B) Download the latest binary of KQEMU from http://fabrice.bellard.free.fr/qemu/qemu-accel.html

C) Move the tarballs to your /usr/local/src directory and deflate
#> sudo mv qemu-version.tar.gz /usr/local/src/
#> sudo mv kqemu-version.tar.gz /usr/local/src/

deflate...
#> sudo gunzip qemu-version.tar.gz; sudo tar -xvf qemu-version.tar
#> sudo gunzip kqemu-version.tar.gz; sudo tar -xvf kqemu-version.tar

D) Install linux-headers for your current kernel version.
If you don't know your current kernel version you can do `uname -r` at the shell to find out...

#> sudo apt-get install linux-headers-`uname -r`

E) Install GCC-3.4 [ qemu complains on GCC-4 ] and libsdl1.2-dev

#> sudo apt-get install gcc-3.4 libsdl1.2-dev

locate the installed gcc-3.4 binary using whereis
#> whereis gcc-3.4

it should be located in /usr/bin/ if not found at all installation failed. repeat step E.
make a note of it's location. you're going to need it in step F

F) Configure and Compile QEMU and KQEMU

change directories to your qemu-source you deflated in step C
#> cd /usr/local/src/qemu-version
#> sudo ./configure --cc=/usr/bin/gcc-3.4 [ remember the location of it from step E? ]

once configuration is completed run make and make install to compile and install... do so as follows

#> sudo make
#> sudo make install

verify that QEMU installed correctly...
#> whereis qemu

change directories to your kqemu-source you deflated in step C, and configure make and make install

#> cd /usr/local/src/kqemu-version
#> sudo ./configure
#> sudo make
#> sudo make install

verify that device node /dev/kqemu exists
if not...execute following commands

#> sudo mknod /dev/kqemu c 250 0
#> sudo chmod 666 /dev/kqemu

Active module KQEMU
#> sudo modprobe kqemu
Verify that it loaded properly
#> lsmod | grep kqemu
If it failed to show up. issue a dmesg | tail to see what the error was
#> dmesg | tail
Anyway... continuing...

[ Step 1 Completed ]
################################################## ################


[ Step 2 ] Installing Guest OS
*notes: you can use either the actual install CD or an ISO made from the original install disk, I used an iso.
you can also use the dd command with the seek option to create your hard disk image file, in place of qemu-img create
for convenience we're going to use the qemu-img binary installed with QEMU

*help: Run qemu/qemu-img without any arguements to view it's help

A) Create the Hard Drive Image File to use as HDA
choose the directory you wish to store your disk images you can use mkdir to create a new one. I use ~/qemu
#> cd ~/qemu
A brief rundown of what we're executing here....
qemu-img create [filename] [-f format( raw, vvfat, cloop,... )] [size G(gigs), M(megs) ]
#> qemu-img create win98.img -f raw 2G
Ok, we've created the 2G image file to install windows98se into....now we load QEMU to boot from the cdrom/iso file specified to start installation

#> qemu -hda win98.img -cdrom /dev/cdrom -boot d -localtime -net nic -net tap
Now QEMU should boot from CD, just follow the steps to complete the installation...

Once installation has completed now we can move onto Step 3
[ Step 2 Complete ]
################################################## ################

[ Step 3 ] Setting up TUN/TAP network interface on HostOS and GuestOS

A) Install uml-utilities via apt
#> sudo apt-get install uml-utilities
B) Load kernel module tun
#> sudo modprobe tun66.202.65.50
C) Create the /dev/net/tun device node
#> mkdir /dev/net
#> mknod /dev/net/tun c 10 200
D) Setup the tap0 interface, with an ip address i use 192.168.100.1 for this.
Create the tap0 interface using tunctl
#> sudo tunctl

Give it an IP-Address
#> sudo ifconfig tap0 192.168.100.1 up
Make sure it was configured properly...
#> ifconfig

You should see tap0 with an inet addr: 192.168.100.1 and a Mask: 255.255.255.0
If there is no mask set...sometimes this happens don't know why but it's happend....do this
#> sudo ifconfig tap0 192.168.100.1 netmask 255.255.255.0 up


Ok, we're done with the HOST side of this

E) Setting up the GuestOS's network configuration

If you don't have QEMU booted into windows already then do so by this command...
#> qemu -hda win98.img -boot c -net nic -net tap &

Once windows has loaded goto your Control panel and open Network Settings
At the configuration tab Select TCP/IP and click properties

In the Properties window
- Select the IP Address Tab
select specify an IP address
enter 192.168.100.2 as your ip address
enter 255.255.255.0 as your subnet mask
- Select the Gateway Tab
add a new gateway as 192.168.100.1
- Select Ok
Select Ok
Now you will be promted for a restart....restart and you should be able to ping the guestOS from the hostOS

F) Testing the network connection
from a terminal
#> ping 192.168.100.2 -c 4
You should reach 192.168.100.2 if not, verify you followed every step.

Make sure you can Ping the Host from the guest

on Windows from a dosprmpt
#> ping 192.168.100.1 -n 4
You should reach 192.168.100.1 if not, verify you followed every step correctly.

[ Step 3 Complete ]
################################################## ###############

[ Step 4 Setting up NAT to allow GuestOS access to the internet ]
*note: i'm going to go ahead and assume you have iptables already installed.

A) Load Required Kernel Modules
#> sudo modprobe ip_tables
#> sudo modprobe iptable_nat
#> sudo modprobe ip_nat_ftp
#> sudo modprobe ip_nat_irc

B) Enable IP-Forwarding
as root run
#> echo "1" > /proc/sys/net/ipv4/ip_forward

If you get your IP Address Dynamically e.g. PPP0 (Dial-up)
as root run
#> echo "1" > /proc/sys/net/ipv4/ip_dynaddr

Enable SNAT (MASQUERADE) functionality on eth0/ppp0
*note: replace eth0 with ppp0 for dialup

#> sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

C) Setup DNS on guestOS
*note: this is for windows98se, methods aren't listed for other OS's

You can retrieve your DNS Server Ip's from your /etc/resolv.conf file after connected to the internet.

#> sudo cat /etc/resolv.conf

In windows, goto control panel -> networking -> TCP/IP Properties -> DNS Configuration
Select Enable DNS

Set Host to your gateway address, i set mine to 192.168.100.1 for my gateway
Set Domain to your Domain i just set it to one of the DNS servers IP Address's
Add your ISP DNS Servers to the DNS List..

Ok, reboot! everything should work fine now..
[ Step 4 Complete ]

After following these steps you should have a working Qemu using the KQEMU accelerator as well as Tun/Tap Virtual Network forwarding Requests from the guest to the internet.
If something isn't working, double check to make sure you set it up correctly.