JP2007089006A - Method for cooperatively finding out disconnected client, and unauthorized access point within wireless network - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method for finding out a disconnected wireless device and an unauthorized radio access point, utilizing the cooperation of neighboring wireless devices. <P>SOLUTION: A central server computes locations of neighboring clients, and calculates the location of a disconnected client using those locations. The techniques utilize the IEEE802.11 beacon mechanism and probe mechanism to prevent a connected client from wasting unnecessary overheads for detecting the disconnected client. Information is collected cooperatively from neighboring devices and is a compared with the database, thereby detecting an unauthorized device and specifying its location. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates generally to network operations, and more particularly to finding disconnected or unauthorized devices in a wireless network.

  For the convenience of wireless networking, wireless networks (eg, IEEE 802.11 networks) are widely used. These networks are deployed at a significant rate in businesses, universities, homes, and public places. But for end users and network administrators, there is still a significant number of “troubles”. Users experience multiple problems, including intermittent connectivity, poor performance, lack of coverage, and authentication failures. These problems occur for a variety of reasons, including improper placement of access points, device misconfiguration, hardware and software errors, the nature of wireless media (eg, interference and propagation), and traffic congestion. Users frequently complain about connectivity and performance issues, and network administrators are expected to diagnose these issues while managing enterprise security and coverage. Their challenges are particularly difficult because of the uncertain nature of wireless media and the lack of intelligent diagnostic tools to determine the cause of these problems.

  For enterprises that have a large deployment of an IEEE 802.11 network, there may be thousands of access points (APs) that span many buildings. Problems with the network result in end-user frustration and lost productivity for the enterprise. Furthermore, eliminating the dissatisfaction of one end user results in additional support personnel costs for the corporate IT department. This cost can be tens of dollars and does not include the cost of losing end-user productivity.

  Fault diagnosis in an IEEE 802.11 infrastructure network has received less attention from research groups than other more high-profile areas in wireless networking research. Several companies have attempted to provide diagnostic tools, but these products lack several desirable features. For example, these products do not perform a comprehensive job of collecting and analyzing data to establish what might be the cause of the problem. Furthermore, most products usually only collect data from APs and ignore the view from the client side of the network. Some products that monitor the network from the client's perspective require hardware sensors, which can be expensive to deploy and maintain. Also, current solutions typically provide no support for disconnected clients, even if they are the most needing clients.

the literature described by P. Bahl and V. N. Padmanabhan in "RADAR: An Inbuilding RF-based User Location and Tracking System," in Proc. of IEEE INFOCOM, Tel-Aviv, Israel, March 2000 the literature described by A. Ladd et al. in "Robotics-Based Location Sensing using Wireless Ethernet," in Proc. of ACM MobiCom, Atlanta, GA, Sept 2002

  This problem, outlined above, can be addressed at least in part by a system and method for detecting and diagnosing faults in a wireless network as described herein.

  The following presents a simplified overview of the present disclosure to provide a basic understanding to the reader. This summary is not an exhaustive or limiting overview of the disclosure. The purpose of providing this summary is not to identify key and / or essential elements of the invention in any way, nor to define the scope of the invention or to Nor is it limiting the scope. Its sole purpose is to present some of the disclosed concepts in a simplified form as a prelude to the more detailed description that is presented later.

  In one embodiment, the monitoring architecture described herein is used to find client machines that are disconnected from the wireless network. In another embodiment, this architecture is used to detect rogue or unauthorized access points within an enterprise wireless network.

  In one embodiment, a computer-readable medium is provided that includes computer-executable instructions for determining a location of a disconnected wireless computing device, the wireless computing device being disconnected from an infrastructure network. And the computer-executable instructions are executed on one or more connected wireless computing devices in the vicinity of the disconnected device and the one or more beacon signals from the disconnected device , Receiving signal strength information about the disconnected device according to the beacon signal, and notifying the diagnostic server that the disconnected device is not connected to the infrastructure network. And transmitting signal strength information to the diagnostic server to estimate the location of the disconnected device, and the beacon signal indicates that the disconnected device is not connected to the infrastructure network. Sent by the device in response to being determined.

  In another embodiment, a computer readable medium comprising computer executable instructions for determining the location of a disconnected wireless computing device is provided, the wireless computing device being disconnected from an infrastructure network. And in the vicinity of one or more wireless devices connected to the infrastructure network, the computer-executable instructions are executed on the server to provide one or more signal strength information about the disconnected devices. Receiving from the connected device, calculating an estimate of the location of the one or more connected devices, and using the calculated estimate and the received signal strength information, the disconnected device Approximate location To run a step that.

  In yet another embodiment, a method is provided for identifying a rogue wireless access point in an infrastructure network, the method comprising receiving information about a suspicious access point, the information being one or The steps collected by multiple nearby wireless computing devices or access points, comparing the information to the access point database, and the suspicious access point if it is inconsistent with the access point database Identifying as.

  The appended claims describe the particular features of the present invention, which are best understood when the following detailed description is read in conjunction with the accompanying drawings. Can do.

  Although a method and system for locating a disconnected client and detecting rogue access points will be described with reference to the preferred embodiments, the method and system of the present invention are not limited thereto. . Moreover, those skilled in the art will readily appreciate that the methods and systems described herein are merely exemplary and that variations can be made without departing from the spirit and scope of the invention. Upon review of this description, it should be apparent to those skilled in the art that the content of the description is merely exemplary and is provided by way of example and not limitation. Many modifications and other exemplary embodiments are within the scope of one of ordinary skill in the art and are considered to be within the scope of the present invention. In particular, many of the examples presented herein include specific combinations of method steps and system elements, but combining the steps and elements in other ways has the same purpose. It should be understood that can be achieved. Steps, elements, and features discussed in connection with only one embodiment are not intended to be excluded from a similar role in other embodiments. Further, the use of ordinal terms such as “first” and “second” within a claim to modify the claim element per se is intended for one claim element relative to another claim element. It does not indicate any priority, dominance, or order, or the temporal order in which the steps of the method are performed, but one claim element that has a name (except for the use of ordinal terms) It is only used as a label to distinguish it from other elements it has, to distinguish the elements of the claim.

  Listed below are many of the problems faced by users and network administrators when using and maintaining enterprise wireless networks.

  Connectivity issues: End users complain about inconsistencies or lack of network connectivity in certain areas of the building. Such “dead spots” or “RF holes” may occur due to weak RF signals, lack of signals, changes in environmental conditions, or obstacles. Finding RF holes automatically is important for radio administrators. As a result, they can change the AP placement within the area in question, increase the AP density, or improve power coverage on nearby APs to improve coverage. The problem can be solved by adjusting.

  Performance issues: This category includes all situations where clients see performance degradation, eg low throughput or long latency. Reasons for performance problems include, for example, traffic slowdown due to congestion, RF interference from microwave ovens and cordless phones, multipath interference, improper network planning or improperly configured clients / APs There can be multiple reasons such as co-channel interference. Performance problems may also arise as a result of problems in the non-wireless part of the network, for example due to slow servers or proxies. Therefore, it is useful for the diagnostic tool to be able to determine whether the problem is in the wireless network or in other parts. In addition, identifying causes within the wireless portion is important to allow network administrators to better configure the system and improve the experience for the end user.

  Network security: Large enterprises often use solutions such as IEEE 802.1x to protect their networks. However, if an employee unknowingly compromises network security by connecting an unauthorized AP to the corporate network's Ethernet tap, a nightmare scenario occurs for IT managers. To do. This problem is generally referred to as “illegal AP problem”. These rogue APs are one of the most frequent serious breaches to wireless network security. The presence of such APs allows external users to access resources on the corporate network, which can leak information or cause other damage. Furthermore, a rogue AP may cause interference to other nearby access points. Since detecting rogue APs through a manual process in a large network is expensive and time consuming, it is important to proactively detect such APs.

  Authentication problems: According to IT support group logs, several complaints are related to the inability of users to authenticate themselves to the network. In wireless networks that are protected by technologies such as IEEE 802.1x, authentication failures are usually due to the absence of a certificate or its expiration date. It is therefore important to detect such authentication problems and assist the client in bootstrapping a valid certificate. The present invention will be more fully understood through the following detailed description, which should be read in conjunction with the accompanying drawings. In this description, like numerals refer to like elements in various embodiments of the invention. Aspects of the invention are illustrated as being implemented in a suitable computing environment. Although not required, the invention will be described in the general context of computer-executable instructions, such as procedures, being executed by a personal computer. In general, a procedure includes program modules, routines, functions, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Further, the present invention can be implemented with other computer system configurations including handheld devices, multiprocessor systems, microprocessor-based home appliances or programmable home appliances, network PCs, minicomputers, mainframe computers, etc. Those skilled in the art will understand. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices. The term computer system can be used to refer to a system of computers as found in a distributed computing environment.

  FIG. 1 illustrates an example of a suitable computing system environment 100 on which aspects of the invention may be implemented. The computing system environment 100 is only one example of a suitable computing environment and is not intended to present any limitation as to the scope of use or functionality of the invention. Neither should the computing system environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 100. One embodiment of the present invention actually includes each component shown in exemplary operating environment 100, but in another more exemplary embodiment of the present invention, for non-essential components such as network communications. Input / output devices other than those required are excluded.

  With reference to FIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 110. The components of computer 110 can include, but are not limited to, processing device 120, system memory 130, and system bus 121 that couples various system components including system memory to processing device 120. The system bus 121 can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such an architecture is known as an ISA (Industry Standard Architecture) bus, an MCA (Micro Channel Architecture) bus, an EISA (Enhanced ISA) bus, a VISA (Video Electronics Standards bus, also known as a local bus) (Peripheral Component Interconnect) bus, including but not limited to.

  Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. For example, computer readable media can include, but is not limited to, computer storage media and communication media. Computer storage media includes volatile and nonvolatile media implemented in any method or technique for storing information such as computer readable instructions, data structures, program modules, other data, and removable and non-removable media Includes media. Computer storage media can be RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage Including, but not limited to, devices or any other media that can be used to store desired information and that can be accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. For example, communication media include, but are not limited to, wired media such as a wired network or direct wired connection, and wireless media such as sonic media, RF media, infrared media, and other wireless media. Also, any combination of the above is included within the scope of computer-readable media.

  The system memory 130 includes computer storage media in the form of volatile and / or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. The basic input / output system 133 (BIOS) includes a basic routine for assisting information transmission between elements in the computer 110 during startup, and is normally stored in the ROM 131. The RAM 132 typically includes data modules and / or program modules that are immediately accessible to and / or being manipulated by the processing device 120 at that time. FIG. 1 shows an operating system 134, application programs 135, other program modules 136, and program data 137 as examples, but is not limited thereto.

  The computer 110 may also include other removable / non-removable, volatile / nonvolatile computer storage media. FIG. 1 shows, for illustrative purposes only, a magnetic read / write between a hard disk drive 141 that reads / writes to / from a fixed nonvolatile magnetic medium and a removable nonvolatile magnetic disk 152. An optical disc drive 155 that reads and writes between the disc drive 151 and a removable nonvolatile optical disc 156 such as a CD-ROM or other optical media is shown. Other removable / fixed, volatile / nonvolatile computer storage media that can be used in typical operating environments include magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state There is a ROM, but it is not limited to these. The hard disk drive 141 is normally connected to the system bus 121 via a fixed memory interface such as the interface 140, and the magnetic disk drive 151 and the optical disk drive 155 are usually connected to the system bus 121 via a removable memory interface such as the interface 150. It is connected to the.

  The above-described drive and associated computer storage media shown in FIG. 1 provide storage of computer-readable instructions, data structures, program modules, and other data for computer 110. For example, in FIG. 1, hard disk drive 141 is illustrated as storing operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Here, different numbers are assigned to indicate that the operating system 144, application program 145, other program modules 146, and program data 147 are at least different copies. A user may enter commands and information into the computer 110 through input devices such as a tablet or electronic digitizer 164, a microphone 163, a keyboard 162, and a pointing device 161, commonly referred to as a mouse, trackball or touch pad. . Other input devices (not shown) can include joysticks, game pads, satellite dish, scanners, and the like. These and other input devices are often connected to the processing unit 120 via a user input interface 160 coupled to the system bus, such as a parallel port, game port, universal serial bus (USB), etc. It can also be connected by other interfaces and bus structures. A monitor 191 or other type of display device can also be connected to the system bus 121 via an interface, such as a video interface 190. The monitor 191 can be integrated with a touch screen panel or the like. It should be noted that the monitor and / or touch screen panel can be physically coupled to a housing in which the computer 110 is built, as in a tablet-type personal computer. In addition, a computer such as computing device 110 may also include other peripheral output devices such as speaker 197 and printer 196, which may be connected via peripheral output interface 194 or the like.

  Computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as remote computer 180. The remote computer 180 can be a personal computer, server, router, network PC, peer device, or other common network node, although only a memory storage device 181 is shown in FIG. Including many or all of the above-described elements associated with 110. The logical connections shown in FIG. 1 include a local area network (LAN) 171 and a wide area network (WAN) 173, but can also include other networks. Such networking environments are common in offices, enterprise-wide computer networks, intranets, and the Internet.

  When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172 can be internal or external and can be connected to the system bus 121 via the user input interface 160 or other suitable mechanism. In a networked environment, program modules illustrated in connection with computer 110, or portions thereof, may be stored in a remote memory storage device. Although FIG. 1 shows the remote application program 185 as resident on the memory device 181 as an example, the present invention is not limited to this form. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used. In particular, the computer 110 preferably includes a wireless networking interface or wireless card that operates according to the IEEE 802.11 protocol.

  In one embodiment of the present invention, the system is comprised of a plurality of components, as shown in FIG. The diagnostic client (DC) 202 is software that runs on the wireless client machine 204. A diagnostic AP (DAP) 206 operates on the access point 208. The diagnostic server (DS) 210 runs on the organization's back-end server 212.

  In some embodiments of the present invention, the diagnostic client module 202 monitors the RF environment and the flow of traffic from neighboring clients 214 and APs 216. During normal activity, the client's wireless card is not set to promiscuous mode. The DC 202 performs local fault diagnosis using the collected data. Depending on the particular failure detection mechanism, this summary of data is sent to the DAP 206 or DS 210, preferably at regular intervals. In addition, the DC 202 is programmed to accept commands from the DAP 206 or DS 210 to perform on-demand data collection, such as switching to mixed mode and analyzing nearby client performance issues. If the wireless client 204 is disconnected, the DC 202 records the data in a local database / file. This data can then be analyzed by DAP 206 or DS 210 when network connectivity is restored at some point thereafter.

  The diagnostic AP 206 accepts diagnostic messages from the DC 202, merges those messages with its own measurements, and sends a summary report to the DS 210. Some embodiments of the present invention do not include a diagnostic AP 206. The DAP 206 reduces the work load on the DS 210. Some embodiments of the present invention include a mixed form of conventional AP 220 and DAP 206, where if the AP is a conventional AP 220, its monitoring function is performed by DC 202 and its summarization function and check is performed by DS 210. .

  Diagnostic server 210 accepts data from DC 202 and DAP 206 and performs appropriate analysis to detect and diagnose various faults. The DS 210 can also access a database 221 that stores the location of each AP 208. The network administrator can balance the load by deploying multiple DSs 210 in the system, for example, by hashing the MAC address of each AP to a specific DS 210. In some embodiments, the diagnostic server 210 interacts with other network servers such as RADIUS 230 and Kerberos 232 servers to obtain client authentication and user information.

  The exemplary system described with reference to FIG. 2 supports both reactive monitoring and proactive monitoring. In proactive monitoring, the DC and DAP continuously monitor the system and alert the network administrator to investigate if an anomaly is detected by the DC, DAP, or DS. The reactive monitoring mode is used when support personnel want to diagnose user dissatisfaction. Support personnel can instruct specific DCs from one of the DSs to collect and analyze data to diagnose the problem.

  This typical system imposes little overhead on power management. Both proactive and reactive technologies described below consume very little bandwidth, CPU, or disk resources, and as a result have little impact on battery consumption. The exemplary system architecture shown in FIG. 2 supports multiple functions in embodiments of the present invention by using DC, DAP, and DS. Some of the supported features include finding disconnected clients, assisting disconnected clients, isolating performance issues, and detecting rogue access points. including.

  In some embodiments of the present invention, the DAP 206 is a modification of the software on the AP 208 to allow for better scalability and AP performance analysis. Since no hardware modification is required, there are fewer restrictions on deploying this embodiment.

  Client machine 204 and access point 208 are preferably capable of controlling beacons and probes. Furthermore, the client machine 204 is preferably capable of initiating an infrastructure network (ie becoming an AP) or capable of initiating an ad hoc (ie computer-to-computer) network, and this capability is currently commercially available. Supported by many wireless cards. Some embodiments of the present invention take advantage of the presence of nearby clients or access points. By utilizing nearby clients and access points with software “sensors”, the cost of deployment is potentially reduced.

  The backend server 212 preferably uses a database to maintain the location of all access points in the network. Such a location database is preferably maintained by a network administrator.

  The exemplary system shown in FIG. 2 can scale with the number of clients and APs in the system. This system includes two shared resources, DS and DAP. It is preferable to add additional DSs as the system load increases so that a single diagnostic server does not become a potential bottleneck. Further, in some embodiments, each individual DS can reduce the workload by sharing the diagnostic load with the DC and DAP, and the DS cannot DC and DAP diagnose the problem, Used only when the analysis requires an overall perspective and more data (eg, signal strength information from multiple DAPs may be needed to find disconnected clients) .

  Similarly, because DAP is a shared resource, having DAP do extra work can potentially impair the performance of all its associated clients. To alleviate the load on the DAP, some embodiments of the present invention use an optimization technique that allows the AP to perform active scanning (if any client is associated with the AP). Active scanning) is not executed, and the associated client executes these operations as necessary. The AP continues to carry out passive monitoring activities, which have only a minor impact on its performance. If there is no associated client, the AP is in a waiting state and can perform these monitoring operations. This approach ensures that most of the physical area around the AP is monitored without compromising AP performance.

  In one embodiment, interactions between DC, DAP and DS are protected using EAP-TLS certificates issued via IEEE 802.1x. Authorized certification authorities (CAs) issue certificates to DCs, DAPs and DSs, and use these certificates to ensure that all communications between these entities are mutually authenticated. One embodiment includes known techniques for detecting malicious activity by legitimate users.

  The ability to automatically find disconnected wireless clients within a fault diagnosis system proactively address problem areas in the deployment, such as poor coverage and high interference (finding RF holes) Potentially useful in determining or finding APs that can cause failure. In an embodiment of the present invention, if a disconnected client does not hear a beacon from any AP (as opposed to being disconnected for some other reason, such as an authentication failure), It is determined that the user is in the RF hall. In order to determine the approximate location of the disconnected client (and thus to assist in finding the RF hole), these embodiments are described in DIAL (Double Indication for Applicating Location) described with reference to FIG. Use a technique called

  If the client 302 notices that it is disconnected in step 304, it becomes an AP or initiates an ad hoc network, and starts transmitting beacons in step 306. To determine the approximate location of this client, nearby connected clients 308 hear the beacon of this client 302 at step 310 and record the signal strength (RSSI) of these packets at step 312. In step 314, the nearby connected client 308 informs the DS 316 that the client 302 has been disconnected and transmits the collected RSSI data. Then, at step 318, the DS 316 performs the first DIAL step to determine the location of the connected client. This can be done using any location identification technique known in documents such as Non-Patent Document 1 and Non-Patent Document 2. In step 320, the DS 316 estimates the approximate location using the location of the connected client as the “anchor point” and the RSSI data of the disconnected client. This step can be done using any scheme that uses RSSI values from multiple clients to determine the location of the machine, such as the scheme described in the above references, or by any other known method. Preferably it is performed. Finding a connected client results in some error, and thus finding the disconnected client by these anchor points can further widen the error. However, experience has shown that this error is about 10 to 12 meters, which is acceptable in estimating the location of a disconnected client.

  With reference to FIG. 4, a method for detecting rogue APs according to an embodiment of the present invention will be discussed. A rogue AP is an unauthorized AP connected to an Ethernet tap in a corporate or university network, which results in security holes and unwanted RF and network loads. May lead to. Unauthorized APs are regarded as a serious security problem for corporate wireless LANs. By using clients and APs (if possible) to monitor their surrounding environment, embodiments of the present invention detect rogue APs. The approach is to have the client and DAP collect information about nearby access points and send it to the DS. When the DS receives information about AP X, the DS checks the AP location database to confirm that X is a registered AP in the expected location and channel. This approach detects rogue APs using commercially available IEEE 802.11 compliant hardware. This is sufficient to serve as a low-cost mechanism to address the common case of rogue AP issues encountered in current deployments, and for many network administrators, the primary goal is Detecting APs that are inadvertently installed by employees for experimentation or convenience. Other embodiments may also perform non-compliant rogue access point and client detection. When two companies have adjacent wireless networks, the access points of other companies are preferably detected as rogue APs. If this classification is unacceptable, each company's network administrator can share their AP location database.

  Each DC 402 monitors packets in its vicinity (in unmixed mode) and sends a 4-tuple of <MAC address, SSID, channel, RSSI> to DS 406 for each AP 404 it detects. To do. Basically, this 4 tuple uniquely identifies an AP for a particular location and channel. To obtain this information, DC 402 determines the MAC addresses of all surrounding APs 404.

  The DC 402 can obtain the MAC address of the AP 404 by switching to mixed mode and observing the data packet (this uses the FromDS and ToDS bits in the packet, which address belongs to that AP. Can be determined). However, it is preferable to achieve the same effect using the following approach. Since IEEE 802.11 requires that all APs transmit beacons at regular intervals in step 408, DC 402 attempts to listen to those beacons in step 410 and in step 412 all that can be heard. The MAC address from the AP 404 beacon is obtained from among the APs. DC 402 has been shown not only to hear beacons on that channel, but also to hear beacons from overlapping channels, and this property increases the likelihood that a rogue AP will be detected.

  These embodiments use the IEEE 802.11 protocol Active Scanning mechanism, even if there are no clients on any channel that overlaps the AP, so that rogue APs do not leak from detection. If (for example, a diagnostic client operating on a wireless computer or access point) wants to know which AP 404 is in the vicinity, it goes to each of the 11 (802.11b) channels and sends a probe request in step 414 To do. The client 402 waits in step 416 for probe responses to be returned from all APs listening to those probe requests, and the DC obtains the MAC address of the AP 404 from these responses in step 418. All APs compliant with IEEE 802.11 must respond to such requests, and some chipsets do not provide control to disable this feature. It is preferable to use Busy AP Optimization so that an active scan in the vicinity of the AP is performed by the AP only if the AP does not have a client associated with it. In the embodiment of the present invention, it is preferable to execute Active Scanning on demand, for example, in response to a request from a network administrator when communicating via a diagnostic client and a diagnostic access point. Alternatively, Active Scanning is performed regularly on a regular basis or according to a policy set by the network administrator.

  When the client 402 collects the AP information, the client 402 transmits a 4-tuple to the DS 406 in step 420. The DS 406 then determines in step 422 whether the AP is an unauthorized AP. This will be described in more detail later.

  Referring to FIG. 5, when the DS receives information for the AP from various clients at step 502, the DS uses the DIAL at step 504 to locate these clients in the manner described above with reference to FIG. And estimate the approximate location of the AP based on the RSSI value of the AP. The DS is expected in step 506 if the 4 tuple does not correspond to a known legitimate AP in the DS's AP location database, ie its MAC address does not exist in the database, or in step 508 an AP is expected. If it is not, or in step 510, the SSID does not match the expected SSID (s) in the organization, the AP is classified as rogue. In some embodiments, if an AP's SSID corresponds to an SOS SSID, the AP can be considered substantially equivalent to a disconnected client performing the connection setup phase of the Client Conduit protocol. Therefore, DS omits further analysis. Channel information is used in slightly different ways. As mentioned above, if an AP is on a channel, it can listen on the overlapping channel. Thus, in step 512, an AP is classified as rogue only if it is reported on a channel that does not overlap with the channel on which the AP is expected to be present. If the channel on the AP changes, the DAP preferably requests the DS to update its AP location database (recall that the communication between the DAP and the DS is authenticated. If it is a conventional AP, the administrator can update the AP location database if the channel of the AP is changed).

  An unauthorized APR may attempt to impersonate using a MAC address to avoid being detected, i.e., send a packet using a MAC address corresponding to a real APG. However, the DS in the embodiment of the present invention still detects R. This is because R is in a different position or channel than G (if R is in the same channel and position as G, G immediately detects R). Note that even if a rogue AP does not send the SSID in its beacon, the rogue AP is still detected because the DC can still get the AP's MAC address from that beacon. Alternatively, such unauthorized APs are also detected by not permitting APs that do not transmit SSIDs within the corporate LAN.

  In an embodiment of the present invention, an unauthorized AP impersonates an existing APX near the location of X, sends a beacon to a valid SSID within the organization, and on any channel where no DC or AP can hear the beacon. May remain undetected for a short time. However, this fraudulent AP will be detected when a nearby client performs an active scan. In order to detect such rogue APs, the DC preferably performs such a scan every 5 minutes.

  Turning attention to FIG. 6, details of one embodiment of one implementation are shown. The basic architecture consists of DC, DAP, and DS daemons running on clients, access points, and servers, respectively. This system can be implemented, for example, with a standard commercially available 802.11b card on the MICROSOFT WINDOWS® operating system. On the DS, the daemon process accepts information from the DAP. The DS reads a list of valid APs from a file or database. The code structure on the DC or DAP preferably includes a user level daemon 602 and kernel level drivers 604 and 606. These elements are structured so that code is added to the kernel drivers 604 and 606 only if the function cannot be achieved within the user-level daemon 602 or if the performance penalty is too high.

  In a typical system, there are two kernel drivers, a miniport driver 604 and an intermediate driver (IM driver) 606, such as the Native WiFi driver in the MICROSOFT WINDOWS® operating system. The miniport driver 604 directly communicates with hardware and provides basic functions such as packet transmission / reception and channel setting. Also, a sufficient interface is presented so that functions such as association and authentication can be processed in the IM driver 606. The IM driver 606 supports multiple interfaces (presented via ioctls) to query for various parameters such as current channel, transmission level, power management mode, SSID. In addition to being able to set these parameters, it allows user-level code to request active scans, associate with specific SSIDs, capture packets, and so on. Overall, it provides a considerable degree of flexibility and control over user level code.

  Although many operations already exist in the IM driver 606, embodiments of the present invention use modifications to present specific functions and modifications to improve the performance of specific protocols. It is preferable to make minimal changes to the miniport driver 604 to present certain types of packets to the IM driver 606. Within the IM driver 606, it is preferable to add support for capturing packet headers and packets, storing RSSI values from received packets, tracking AP information, and kernel event support for protocol efficiency. These modifications are then discussed in more detail.

  Packet header and packet capture: In embodiments of the present invention, only specific packets or packet headers, such as filters based on specific MAC addresses, packet types, packet subtypes (such as management packets and beacon packets), etc. The filter can be set to capture.

  Saving RSSI values from received packets: In an embodiment of the present invention, the RSSI values of all received packets are obtained and the RSSI values from each neighbor (indexed on the MAC address) are tracked. A table called NeighborInfo table is held. An exponentially weighted average is maintained with the new value given some weighting factor, eg, 0.25. The RSSI information is preferably used to estimate the location of clients and APs that have been disconnected using DIAL.

  Tracking AP information: Within the NeighborInfo table, this embodiment tracks the channel on which the packet was heard from a particular MAC address, SSID information (from the beacon), and whether the device is an AP or a station. To do. This information is preferably sent to the DAP / DS to detect unauthorized APs.

  Kernel event support for protocol efficiency: It is preferable to add an event that is shared between kernel-level code and user-level code. The kernel triggers this event when an “interesting” event occurs, which allows some of the protocols to be interrupt driven rather than poll based.

  Furthermore, it is preferable to add a plurality of ioctls to obtain and delete the above information.

  In an embodiment of the invention, the diagnostic daemon 602 runs on the device, collects information, and implements the various mechanisms described above, such as collecting the AP's MAC address to detect rogue APs. If the device is an AP, it communicates diagnostic information with the DS and DC, and if it is simply a DC, the device communicates with its associated AP to convey the diagnostic information. The diagnostic daemon on the DC obtains the latest NeighborInfo table from the kernel 608 at regular intervals, for example every 30 seconds. If any new node is found, or if the existing data has changed significantly (eg, if the client's RSSI value has changed by a factor of 2), the latest NeighborInfo table is sent to the DAP. The DAP also preferably maintains a similar table indexed on the MAC address. However, the DAP only sends information about disconnected clients and APs to the DS, otherwise the DS will receive updates for all clients in the system, reducing its scalability. become. The DAP periodically sends new or changed information about the AP to the DS (eg every 30 seconds). In addition, if the DAP has any pending information about the disconnected client D, the DAP immediately informs the DS of the information so that the disconnected client can be serviced in a timely manner. All messages from DC to DAP and from DAP to DS are preferably sent as XML messages. A sample message format from DC is shown below (time stamps are deleted).

  As shown in the sample message, the DC sends information about other connected clients, APs, and disconnected clients. For each such class of entities, the DC sends the machine's MAC address along with the RSSI, SSID, and a channel bitmap that indicates the channel on which the particular device was heard.

  Given the many possible embodiments to which the principles of the present invention can be applied, the embodiments described herein with reference to the drawings are intended to be illustrative only and are intended to limit the scope of the present invention. It should be recognized that it should not be interpreted. For example, those skilled in the art will recognize that the configuration and details of the illustrated embodiments can be modified without departing from the spirit of the invention. Although the present invention has been described in terms of software modules and software components, those skilled in the art will recognize that these can be equivalently replaced with hardware components. Accordingly, the invention described herein contemplates all embodiments that may fall within the scope of the appended claims and their equivalents.

1 is a schematic diagram illustrating an exemplary architecture for computing used in accordance with an embodiment of the present invention. FIG. FIG. 2 illustrates an exemplary wireless network for locating disconnected clients and rogue access points according to one embodiment of the present invention. 4 is a flow diagram illustrating a method for locating a disconnected client according to an embodiment of the present invention. 4 is a flow diagram illustrating a method for cooperatively obtaining information on access points in a wireless network, according to one embodiment of the invention. 5 is a flow diagram illustrating a method for determining whether an access point is rogue according to one embodiment of the invention. FIG. 3 is a schematic diagram illustrating software components used to locate disconnected clients and rogue access points according to one embodiment of the invention.

Explanation of symbols

120 processor 121 system bus 130 system memory 134 operating system 135 application program 136 other program module 137 program data 140 fixed nonvolatile memory interface 144 operating system 145 application program 146 other program module 147 program data 150 detachable nonvolatile Memory interface 160 user input interface 161 mouse 162 keyboard 170 network interface 171 local area network 172 modem 173 wide area network 180 remote computer 185 remote application program 190 video interface 195 peripheral output in Over the face 196 printer 197 speaker 202 diagnostic client 206 diagnostic access point 208 access point 210 diagnostic server 220 conventional access point 602 diagnostic daemon 604 Diagnostic miniport module 606 Diagnostics IM module

Claims (20)

A computer-readable medium comprising computer-executable instructions for determining a location of a first wireless device, the computer-executable instructions being located in the vicinity of the first device and connected to an infrastructure network Running on one or more other wireless devices,
Receiving one or more signals from the first device;
Recording signal strength information about the first device according to the signal;
Performing the step of transmitting the signal strength information to a diagnostic server to estimate the position of the first device;
The diagnostic server is
Receiving the transmitted signal strength information;
Calculating a position estimate of the one or more other wireless devices;
Approximating the position of the first device using the received signal strength information and the calculated estimate of the position of the one or more other wireless devices. A computer readable medium for estimating the position of a device.   The computer-readable medium of claim 1, wherein the signal is a beacon signal.   The computer of claim 1, wherein the signal is transmitted by the first device in response to determining that the first device is not connected to the infrastructure network. A readable medium.   The computer-readable medium of claim 1, wherein the first device is a rogue or faulty wireless access point.   The computer-readable medium of claim 1, wherein the location of the first device is approximated with an error within about 12 meters.   The computer-readable medium of claim 1, wherein the position of the first device substantially matches an RF hole. A computer-readable medium comprising computer-executable instructions for determining a location of a first wireless device, the wireless device being in the vicinity of one or more other wireless devices connected to an infrastructure network The computer-executable instructions are executed on a server;
Receiving signal strength information regarding the first device from the one or more other devices;
Calculating a position estimate of the one or more other wireless devices;
Performing the step of estimating the position of the first device using the calculated estimate and the received signal strength information. The one or more other devices are:
Receiving one or more beacon signals from the first device;
Recording signal strength information regarding the first device according to the beacon signal;
The computer-readable medium of claim 7, performing the step of transmitting the signal strength information to estimate the position of the first device.   The beacon signal is transmitted by the first device in response to determining that the first device is not connected to the infrastructure network. Computer readable medium.   The computer-readable medium of claim 7, wherein the first device is a rogue or faulty wireless access point.   The computer-readable medium of claim 7, wherein the position of the first device is approximated with an error within about 12 meters.   The computer-readable medium of claim 7, wherein the location of the first device substantially matches an RF hole. In a method for identifying rogue wireless access points in an infrastructure network,
Receiving information regarding a suspicious access point, wherein the information is collected by one or more nearby wireless computing devices or access points;
Comparing the information to an access point database;
Identifying the suspicious access point as fraudulent if the information is inconsistent with the access point database.   The method of claim 13, wherein the information includes a combination of one or more of signal strength information, MAC address, SSID, and channel information.   The method of claim 13, wherein the information includes a MAC address, and the MAC address is obtained by the one or more nearby wireless devices by listening to a beacon of the suspicious access point. The information includes a MAC address, and the MAC address is
Sending a probe request; and
Receiving a probe response from the suspicious access point;
14. The method of claim 13, obtained by the one or more nearby wireless devices by performing a method comprising retrieving the MAC address from the probe response. The information includes signal strength information, and the method includes:
Using the received signal strength information to estimate the location of the suspicious access point;
The method of claim 13, further comprising identifying the suspicious access point as fraudulent if the estimated location does not match the access point database. The step of estimating the position includes:
Calculating an estimate of the location of the nearby wireless computing device or access point;
18. The method of claim 17, further comprising: further estimating the location of the suspicious access point using the calculated estimate and received signal strength information. The information includes channel information, and the method includes:
And further comprising identifying the suspicious access point as a rogue when the suspicious access point is transmitting on a channel that does not overlap the channel indicated in the access point database. The method of claim 13. The method of claim 13, further comprising updating the access point database with new information in response to receiving an update request from an authenticated access point.

Images