2G1701 Advanced Internetworking Group 5 : KiStaNEt ISP Project Report

Transcription

1 2G1701 Advanced Internetworking Group 5 : KiStaNEt ISP Project Report Course staff : Group Members : Jon-Olov Vatn (Course Leader) Sermed Al-abbasi (Teaching Assistant) Zaheen Sherwani Carlos Loarca Xiong Si Wen-Jia Gan Abstract This report details what went behind the setting up of KiStaNet ISP, and our motivations behind our design decisions, and summarizes what we all have learnt in the process. i

2 Table of Contents Page Number 1. Introduction 1 2. Description of Services 1 3. Description of Setup Detailed Setup Description of Individual Machines 4 4. Results 5 5. Individual Statements 5 6. Lessons Learned 6 7. Summary 6 8. References 6 Appendixes 7 Appendix A. : Verification Tests 7 Appendix B. : Configuration Files named.conf 8 db.kistanet.lab 9 db db dhcpd.conf 10 hostapd.conf 11 ii

3 1. Introduction The purpose of the project is to setup and run an Internet Service Provider (ISP) as a group. The tasks our group are to solve includes the mandatory services of Domain Name Services (DNS), web server, dynamic routing and dynamic address assignment. The selective service our group chose to do is Wireless LAN (WLAN), which enable hosts to connect and obtain IP address dynamically via cable or wirelessly. Due to manpower limitations of only 4 people in our group, our scope is limited to simple web server services. 2. Description of Services This section describes our services in more depth, and also how we have decided to provide the services. One major reason for the choice of implementations is due to the prior experiences and familiarity by the KSN technical staff. 2.1 Mandatory services DNS As the Internet's IP addresses are not generally user-friendly, Kistanet (KSN) domain name servers were used to resolve domain names to IP addresses. The relationship between IP addresses and domain names was managed by a primary domain name server (ns.kistanet.lab) and a secondary domain name server (ns2.kistanet.lab). KSN used the secondary DNS to provide redundancy to the customers. Users would otherwise not be able to access any Uniform Resource Locator (URL i.e. web page) if the primary DNS failed, unless the user knew the exact IP address. KSN is a start-up ISP company with not many resources. Therefore, KSN prefers to provide a DNS service using open source implementations (BIND) coordinated by The Internet Software Consortium. Meanwhile KSN will be trying to develop its own implementation to solve some security problems with BIND in the future. Web Server Our web server is running on Apache 2, which is the most popular web server implementation available today, together with PHP server side scripting and PostGreSQL database. Our ISP main webpage allows user login and authentication based on the above services. We have opted a rudimentary web server is provided instead of additional web services deployed due to manpower limitations. 1

4 Dynamic Routing KSN decided to use dynamic routing within the ISP setup ie on both interfaces of routers R1, R2, R3 and R4 to avoid the overhead of manually entering the static routes within the network. The link state Open Shortest Path First Protocol (OSPF) was selected for the dynamic routing protocol within the ISP network due to its low overhead and faster convergence time. OSPF is widely used in large networks such as ISP backbone and enterprise network. In order to provide dynamic routing, Zebra dynamic routing software package was used within the ISP setup. The advantage of using Zebra is that it provides a console based interface for the configuration of personal computer (PC) based routers running Linux environment. This interface is very similar to that developed by Cisco Systems for the configuration of their commercial routers. Since Zebra and OSPF process daemons are controlled through separate telnet sessions therefore a telnet server was also installed on these Linux machines. Dynamic Address Assignment There are many commercial Dynamic Host Configuration Protocol (DHCP) implementations available, such as Vicomsoft, 602ProLan Suite, IP Commander etc. We have chosen to use DHCP distribution from the Internet Software Consortium as it provides full functionality and is freely distributable. DHCP can be used by client machines in a plug-n-play fashion into our network and be assigned IP addresses with basically no configuration required on their part. 2.2 Selective services : Wireless LAN (WLAN) We chose Wireless LAN (WLAN) as our selective service as it is an up and coming field. Its setup had provided great learning value. WLAN services provided by ISPs is becoming popular as wireless hotspots usually located at cafes, restaurants, airports and hotels. 2

5 3. Description of Setup This section described our network design and machine setup. Our ISP s network topology is illustrated in Figure 1. Figure 1 : KiStaNet Network Topology Diagram ns /24 ns.lab / / / <100+N>/24 R1 ISP1 R2 ISP2 Sec. DNS R1 ISPN Internal network of ISP 1 Internal network of ISP 2 Internal network of ISP /24 Internal network of ISP N (WWW) (DNS) R1 ISP5 Del. DNS (Delegation DNS) / /24 (add range ) Dynamic IP WLAN H R / /24 R / / / /124 R4 (DHCP) /24 (add range ) WLAN H Dynamic IP Dynamic IP Dynamic IP H H /24 3

6 3.1 Detailed Setup Description of Individual Machines This section describes how we have setup our services. DNS The domain contained: www mail mail.kistanet.lab The KSN domain names hierarchy consisted of a primary DNS (R1) and a secondary DNS (hosted on another ISP) to give the IP address mapping to a name and vice versa. A delegation server was also added for controlling the sub-domain of the KTH University (ns.kth.kistanet.lab). It was advantageous to delegate control from the domain to the sub-domains to simplify name resolution, for example to cater for when the ISP company grows. This sub-domain contains: web ftp ftp.kth.kistanet.lab mail.kth.kistanet.lab servers mail2.kth.kistanet.lab Web Server R1 is running Apache 2 web server, PHP server side scripting and PostGreSQL database. Dynamic Address Assignment R4 is running DHCP server for subnet (wired LAN) and (wireless LAN). Wireless LAN We made R4 act as an Access Point (AP). It had one interface connected via wire to our ISP network, with another interface that has a Wireless LAN card running on a Intersil's Prism 2/2.5/3 chipset. This PC need to run a software called HostAP for it to take care of IEEE management functions in the host computer and acts as an access point. Intersil's station firmware for Prism2 chipset supports a so called Host AP mode in which the firmware takes care of time critical tasks like beacon sending and frame acknowledging, but leaves other management tasks to host computer driver. Our PC providing WLAN runs Red Hat 9 with kernel version and use the stable release of HostAP. Using HostAP, the WLAN card is set as Master mode to enable it to function as an AP. It s Extended Service Set Identifier (ESSID) is set to WKSN (Wireless Kistanet) to differentiate our WLAN from others. Our AP has DHCP server to assign IP address dynamically, and also runs OSPF for dynamic routing. Access Control To implement access control, we ran hostapd, which is a user space daemon for extended IEEE management, that came with the HostAP distribution. We implemented station MAC address-based authentication, and specified in the hostapd.conf configuration file to deny all stations unless of those MAC addresses listed in /etc/hostapd.accept accept list. 4

7 4. Results We first tested for connectivity to the web servers of the other ISPs from host machines in our ISP network, by pinging. We then proceeded to resolve domain names of other ISPs, as well as others being able to resolve ours, successfully. This included normal lookup and reverse lookup of addresses. We also used web browsers to access the web pages of the other ISP s web server. To test our dynamic routing, we disconnected one of the routers (R2 and R3). Our end hosts were still able to reach the other ISPs web server, while maintaining local network connectivity. We then changed over to the disconnected router, and achieved the same results. Our end hosts were able to get IP addresses dynamically, both on the wired LAN and wireless LAN. We also tested for wireless LAN access control by allowing connection to authorized hosts with registered MAC addresses. A wireless client from another ISP was also able to get a dynamic IP address from our access point and got connected to our network. 5. Individual Statements This section is where each student in the group individually confirms that we know how to setup each of the services that the group is required to do (the mandatory services as well as the selected service.) Carlos Loarca I confirm that I know how to set up the mandatory and selective services that our group is required to do. Wen-Jia Gan I confirm that I know how to set up the mandatory and selective services that our group is required to do. Xiong Si I confirm that I know how to set up the mandatory and selective services that our group is required to do. Zaheen Sherwani I confirm that I know how to set up the mandatory and selective services that our group is required to do. 5

8 6. Lessons Learnt Carlos Loarca The theory is very important since fits completely with the practical experiences generating the best learning environment. I was so sorry when I couldn't read every thing what I needed to read for a laboration, once. But when you have done it for sure you get a good knowledge. In the other hand, I feel more confident using on Linux now at days than before starting this course and also I'm encouraged to research and play with some other services on Linux. Wen-Jia Gan This project had given us the opportunity to hone our network design, and troubleshooting skills. The research and experimentations while doing the project had been most valuable. Xiong Si First, I realize that group cooperation is really important. Second, this project give me a lot of practical experiments, and combine the knowledge on book with practical applications. Zaheen Sherwani Apart from learning the subject, I realised the importance of working in groups. We learnt from each others weaknesses and strengths, and were able to achieve our goals through mutual cooperation. Secondly, at the beginning of the course I did not know much about Linux, now I am comfortable in it. 7. Summary In all, this ISP group project provided invaluable learning experience to us all, in both areas of practical work and teamwork. 8. References Guidelines for ISP Project Demonstration Guidelines for ISP Project Report Internet Software Consortium (ISC) Dynamic Host Configuration Protocol (DHCP) Host AP driver for Intersil Prism2/2.5/3 Appendixes 6

9 A. Verification Tests This section describes how we verified that our different services work. DNS We looked up our dns with the following command to inquire the root name server for our web server. dig +trace We are able to obtain answers from root, top level domain and local name servers. We did reverse lookup using : dig x to get the domain name corresponding to this IP address. Web Server We opened a web browser to browse our webpage using a host in our network, and also using a host in other ISP s host machines. Dynamic Routing First we listed our routing table to see which router (R2 or R3) was the default gateway of the end host. We then disconnected that the router. We noted that the default gateway was automatically changed to the other router. We then changed over to the disconnected router, and reachability to the other ISPs remained. Dynamic Address Assignment Our end hosts were able to get assigned IP addresses dynamically to their connected interfaces, on both the wired LAN and wireless LAN. We checked that the IP addresses assigned corresponded to the IP address range given. Wireless LAN Hosts with wireless LAN cards were able to detect the SSID ( WKSN ) of our Access Point, and get assigned dynamic IP addresses by the DHCP server. The hosts were also able to ping hosts in the other ISPs networks. 7

10 B. Configuration Files named.conf options { directory "/var/named"; forward first; forwarders { ; ; controls { inet allow { ; } keys { "rndc-key"; controls { inet allow { ; } keys { "rndc-key"; zone "." in { type hint; file "root.hints"; zone " in-addr.arpa" in { type master; file "kistanet/db "; zone " in-addr.arpa" in { type master; file "kistanet/db "; zone " in-addr.arpa" in { type master; file "kistanet/db "; zone "kistanet.lab" in { type master; file "kistanet/db.kistanet.lab"; # Start of rndc.conf key "rndc-key" { algorithm hmac-md5; secret "qnmtlajk4dcoqceot+a9+g=="; 8

11 db.kistanet.lab $TTL IN SOA ns.kistanet.lab. staff5.kistanet.lab.( ; Serial 3h ; Refresh 1h ; Retry 1w ; Expire 1h) ; Negative TTL kistanet.lab. NS ns.kistanet.lab. NS ns2.kistanet.lab. MX 10 mail.kistanet.lab. ;delegation record kth.kistanet.lab. IN NS ns.kth.kistanet.lab. localhost IN A ;name servers ns IN A ns.kth.kistanet.lab. IN A ;service servers www IN A mail IN A db $TTL IN SOA ns.kistanet.lab. staff5.kistanet.lab.( 1 ; Serial 3h ; Refresh 1h ; Retry 1w ; Expire 1h) ; Negative TTL IN NS ns.kistanet.lab. IN NS ns2.kistanet.lab. ; root name server IN PTR ns. ; top domain server IN PTR ns.lab. ; any type servers 1 IN PTR ;10 IN PTR ns2.kistanet.lab. 15 IN PTR mail.kistanet.lab. ; delegation server 11 IN NS ns.kth.kistanet.lab. 12 IN NS ns.kth.kistanet.lab. 13 IN NS ns.kth.kistanet.lab. 14 IN NS ns.kth.kistanet.lab. ns.kth.kistanet.lab. IN A

12 db $TTL IN SOA ns.kistanet.lab. staff5.kistanet.lab.( 1 ; Serial 3h ; Refresh 1h ; Retry 1w ; Expire 1h) ; Negative TTL NS ns.kistanet.lab. 1 PTR localhost. dhcpd.conf : Configuration file for DHCP server #ddns-update-style interim; ddns-update-style none; ignore client-updates; subnet netmask { range ; # --- default gateway option routers ; option subnet-mask ; option domain-name "kistanet.lab"; option domain-name-servers ; option domain-name-servers ; } default-lease-time 120; max-lease-time 43200; subnet netmask { range ; # --- default gateway option routers ; option subnet-mask ; option domain-name "kistanet.lab"; option domain-name-servers ; option domain-name-servers ; } default-lease-time 120; max-lease-time 43200; 10

13 hostapd.conf : Configuration file for HostAP daemon ##### hostapd configuration file ############################################## # Empty lines and lines starting with # are ignored # AP netdevice name (without 'ap' prefix, i.e., wlan0 uses wlan0ap for # management frames) interface=wlan0 # hostapd event logger configuration # # Two output method: syslog and stdout (only usable if not forking to # background). # # Module bitfield (ORed bitfield of modules that will be logged; -1 = all # modules): # bit 0 (1) = IEEE # bit 1 (2) = IEEE 802.1X # bit 2 (4) = RADIUS # # Levels (minimum value for logged events): # 0 = verbose debugging # 1 = debugging # 2 = informational messages # 3 = notification # 4 = warning # logger_syslog=-1 logger_syslog_level=2 logger_stdout=-1 logger_stdout_level=2 # Debugging: 0 = no, 1 = minimal, 2 = verbose, 3 = msg dumps debug=0 # Dump file for state information (on SIGUSR1) dump_file=/tmp/hostapd.dump # Daemonize hostapd process (i.e., fork to background) daemonize=1 ##### IEEE related configuration ####################################### # SSID to be used in IEEE management frames #ssid=test ssid=wksn # Station MAC address -based authentication # 0 = accept unless in deny list # 1 = deny unless in accept list # 2 = use external RADIUS server (accept/deny lists are searched first) #macaddr_acl=0 macaddr_acl=1 11

14 # Accept/deny lists are read from separate files (containing list of # MAC addresses, one per line). Use absolute path name to make sure that the # files can be read on SIGHUP configuration reloads. accept_mac_file=/etc/hostapd.accept #deny_mac_file=/etc/hostapd.deny # IEEE specifies two authentication algorithms. hostapd can be # configured to allow both of these or only one. Open system authentication # should be used with IEEE 802.1X. # Bit fields of allowed authentication algorithms: # bit 0 = Open System Authentication # bit 1 = Shared Key Authentication (requires WEP) auth_algs=3 # Associate as a station to another AP while still acting as an AP on the same # channel. #assoc_ap_addr=00:12:34:56:78:9a ##### IEEE 802.1X (and IEEE 802.1aa/D4) related configuration ################# # Require IEEE 802.1X authorization #ieee8021x=1 # Use internal minimal EAP Authentication Server for testing IEEE 802.1X. # This should only be used for testing since it authorizes all users that # suppot IEEE 802.1X without any keys or certificates. minimal_eap=0 # Optional displayable message sent with EAP Request-Identity eap_message=hello # WEP rekeying (disabled if key lengths are not set or are set to 0) # Key lengths for default/broadcast and individual/unicast keys: # 5 = 40-bit WEP (also known as 64-bit WEP with 40 secret bits) # 13 = 104-bit WEP (also known as 128-bit WEP with 104 secret bits) #wep_key_len_broadcast=5 #wep_key_len_unicast=5 # Rekeying period in seconds. 0 = do not rekey (i.e., set keys only once) #wep_rekey_period=300 # EAPOL-Key index workaround (set bit7) for WinXP Supplicant (needed only if # only broadcast keys are used) eapol_key_index_workaround=0 ##### IEEE f - Inter-Access Point Protocol (IAPP) ####################### 12

15 # Interface to be used for IAPP broadcast packets #iapp_interface=eth0 ##### RADIUS configuration #################################################### # for IEEE 802.1X with external Authentication Server, IEEE # authentication with external ACL for MAC addresses, and accounting # The own IP address of the access point (used as NAS-IP-Address) own_ip_addr= # RADIUS authentication server #auth_server_addr= #auth_server_port=1812 #auth_server_shared_secret=secret # RADIUS accounting server #acct_server_addr= #acct_server_port=1813 #acct_server_shared_secret=secret # Secondary RADIUS servers; to be used if primary one does not reply to # RADIUS packets. These are optional and there can be more than one secondary # server listed. #auth_server_addr= #auth_server_port=1812 #auth_server_shared_secret=secret2 # #acct_server_addr= #acct_server_port=1813 #acct_server_shared_secret=secret2 # Retry interval for trying to return to the primary RADIUS server (in # seconds). RADIUS client code will automatically try to use the next server # when the current server is not replying to requests. If this interval is set, # primary server will be retried after configured amount of time even if the # currently used secondary server is still working. #radius_retry_primary_interval=600 13