Linux Unwired [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Linux Unwired [Electronic resources] - نسخه متنی

Edd Dumbill, Brian Jepson, Roger Weeks

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








3.2 Wireless Network Discovery


If your network card supports it, the easiest method of locating
available wireless
networks is included with the Wireless Tools, which you installed in
Chapter 2. The
iwlist command supports a
scanning parameter that lists any access points in
range. It's worth noting, however, that some
wireless card drivers do not support this feature. Chief among them
is the orinoco_cs driver. If you're using this
driver, you must use one of the alternative discovery methods next.

To determine if your card and driver support
scanning, execute the
iwlist command with no other parameters. If you
see "scanning" listed in the
output, you should be able to scan for available access points. Note
that you must have root access to use this command.

# iwlist
Usage: iwlist [interface] frequency
[interface] channel
[interface] ap
[interface] accesspoints
[interface] bitrate
[interface] rate
[interface] encryption
[interface] key
[interface] power
[interface] txpower
[interface] retry
[interface] scanning

Once you've determined that you can use the
scanning parameter, execute the command. You must
specify the network adapter that corresponds to your wireless card
(eth1 in the following example). Again, you must
have root access.

# iwlist eth1 scanning
eth1 Scan completed :
Cell 01 - Address: 00:02:6F:01:76:31
ESSID:"NoCat "
Mode:Master
Frequency: 2.462GHz
Quality:0/92 Signal level:-50 dBm Noise level:-100 dBm
Encryption key:off
Bit Rate:1Mb/s
Bit Rate:2Mb/s
Bit Rate:5.5Mb/s
Bit Rate:11Mb/s
Cell 02 - Address: 00:30:65:03:E7:0A
Essid:"SurfandSip "
Mode:Master
Frequency:2.422GHz
Quality:0/92 Signal level:-66 dBm Noise level:-96 dBm
Encryption key:off
Bit Rate:1Mb/s
Bit Rate:2Mb/s
Bit Rate:5.5Mb/s
Bit Rate:11Mb/s

Now that you've obtained a list of available
networks, see what providers are in your area, and make a decision on
the hotspot to use. scanning shows you relative
signal strengths, so pay attention. You don't
necessarily want to associate with the weakest hotspot in the area.

Note also that the scanning output gives you the
frequency of each hotspot as well as whether encryption (WEP) is
enabled.


3.2.1 Kismet


In contrast to the small bit of information you can glean by using
iwlist scanning, Kismet
is a seriously advanced wireless diagnostic tool. It is a passive
network scanner, similar to commercial tools such as Network
Associates' Sniffer Wireless and
Airopeek. It is
designed from the ground up specifically for scanning wireless
networks, so it detects all 802.11 traffic from both access points
and wireless clients. It can find
"closed" networks (some access
points allow you to disable the broadcast of the SSID) by monitoring
traffic sent from clients, and it logs all raw 802.11 frames in
standard pcap(3) format for later use with other
specialized tools such as Ethereal, an open source network protocol
analyzer.

To take advantage of
Kismet's
advanced features, you need a wireless card and driver capable of
entering RF Monitor or promiscuous mode. Cards in this category
include the Prism-based cards using the host_ap driver and the Cisco
Aironet cards using the airo driver. Kismet also works well with
Atheros-based 802.11a/g cards using the madwifi driver. However, if
you need monitor mode in the madwifi driver, download the latest CVS
driver code. Finally, you'll need a patched
orinoco_cs driver or the latest CVS version of the orinoco_cs code to
support monitor mode with Orinoco cards. We covered this in detail in
Chapter 2.

Kismet is available as a package with most distributions.
Debian users can install Kismet using
apt-get:

apt-get install kismet

Red Hat and
Fedora users can obtain RPM packages from
http://www.rpmfind.net. Mandrake
users can install Kismet using urpmi:

urpmi kismet

If you want to read Kismet's dump files in
Ethereal, you must download the source code
for Kismet from http://www.kismetwireless.net. Also, Ethereal
must be installed from source, and the Ethereal source code tree must
be available. Change into the
Kismet
source directory, and configure Kismet as follows:

# ./configure --with-ethereal=/your/ethereal/source/path/here

Once that is done, build
Kismet
with standard compile commands:

make
make dep
make install

Once Kismet is compiled or installed from source, you must edit
/usr/local/etc/kismet.conf to suit your system.
If you've installed from package, the file is
probably located in /etc/kismet.conf. At a
minimum, you must edit the source= line to match
your hardware. The format for this line is
driver,device,description. For example, with a
Prism card, edit the line to read:

source=hostap_cs,wlan0,Prism

See the comments in the kismet.conf file for
more information on supported drivers.

If you want Kismet
to play sound effects when it finds new SSIDs, it will. By default,
it expects /usr/bin/play to be installed, which
is part of the Sox sound utilities, but any command-line audio player
works. All of the audio and other display parameters are configured
in /usr/local/etc/kismet_ui.conf.

When Kismet is running, your wireless card will be in RF monitoring
mode. Note that once in this mode, your card can no longer associate
with wireless networks, so you may not have a network connection.

Now execute the kismet command using your normal user ID. You
don't have to run the Kismet user interface as root.
You should see the Kismet screen as shown in Figure 3-2.


Figure 3-2. The main Kismet screen


Kismet incorporates a hopping algorithm to switch between radio
channels in order to find all the networks in your locations. This
makes your card hop between radio channels. The hop
pattern is configurable to your needs. See the
kismet_hopper manpage for details. Note that newer
versions of Kismet call kismet_hopper
automatically

By default, Kismet initially scans the network list based on the last
time it saw traffic from each network. This list constantly changes,
making it difficult, if not impossible, to select any one network for
more detailed information.

To keep the list from constantly changing, manage the scanning sort
order by hitting s at any time, followed by the
desired sort order. For example, to sort by SSID, hit
ss. Now use the arrow keys to select a network for
further details. Press h at any time to see
keystroke help and q to close any pop-up windows.

To get more information on a specific network, select it using the
arrow keys and press i. You will see a more
detailed screen as shown in Figure 3-3.


Figure 3-3. Kismet's detailed network information


Kismet finds closed networks
(networks that do not broadcast their SSID). If there is no network
traffic coming from a client of that network, Kismet lists the SSID
with a name of <no_ssid>. Once Kismet sees
a frame of traffic from a client, the SSID updates.

Note that your card is now out of monitor mode, but the original
network settings are not returned. You can physically eject the card
and reinsert or execute:

# cardctl reset


3.2.2 AP Radar


The previous methods are perfectly usable and provide you with all
sorts of information regarding the available wireless networks near
you. These are manual methods that don't approach
the level of ease in wireless detection and configuration that is
offered with other operating systems.

AP Radar is an attempt to make detection
of and connecting to wireless networks easier and more manageable. It
is both a graphical network discovery tool and a wireless profile
manager. Using the Wireless Extensions, it has the ability to watch
for wireless networks while staying associated to your existing
network. It focuses on automating tasks, so that when you come in
range of your home network, you are automatically connected.

AP Radar is the work of Don Park, and you can obtain it from the
project's
SourceForge development site at
http://apradar.sourceforge.net.
Currently, it is available as an RPM package or as a source file. In
order to get the package running, you must have GNOME Version 2.
You'll also need a 2.4.20 kernel or higher, or any
2.6 kernel.

To compile AP Radar from source, you must
have the GTK+ header files and libraries, as well as the GTKmm header
files and libraries. Users of Mandrake, RedHat, and other
distributions that use RPM should see the AP Radar README file for a
list of required RPMs.

Debian users should be able to install the same packages via apt-get;
however, you must set up apt to obtain packages from the testing or
unstable trees. See the sources.list manpage for
details.

To build AP Radar from source, uncompress
the source code file and change into the newly created directory. The
commands to compile are standard, although the filename and top-level
directory name will differ if you are using a newer version than we
did:

$ tar xzvf apradar-0.50.tar.gz
$ cd apradar-0.50
$ ./configure
$ make
$ su -c "make install"

AP Radar works with a number of wireless cards and drivers. To
determine whether AP Radar will run with your card
and driver, execute iwlist
scanning:

# iwlist wlan0 scanning

You should see some output like the following:

eth1   Scan completed :
Cell 01 - Address: 00:02:6F:01:76:31
ESSID:"NoCat "
Mode:Master
Frequency: 2.462GHz
Quality:0/92 Signal level:-50 dBm Noise level:-100 dBm
Encryption key:off
Bit Rate:1Mb/s
Bit Rate:2Mb/s
Bit Rate:5.5Mb/s
Bit Rate:11Mb/s

If you see anything else, chances are AP Radar will not function with
your card. Some reasons for this include the use of the following
drivers:

Orinoco_cs driver, wvlan, wavelan, and wavelan2 drivers


None of these drivers currently support wireless scanning. Patches
are available for the orinoco_cs driver to enable scanning, and the
CVS code for orinoco_cs also supports scanning. See Chapter 2 for more details.


host_ap driver


If you are using the newest host_ap code, Version 0.1.3 (as of this
writing), you must execute the following command as root for AP Radar
to function properly:

# iwpriv wlan0 host_roaming 1



Once you install AP Radar and determine that it will function with
your wireless card/driver, simply start it as root:

# apradar

If you experience problems starting AP Radar, it may be due to
oddities in your wireless card driver and how it writes status to
/proc/net/wireless. In order to avoid this
problem, start AP Radar by specifying the interface name (ath0 in the
following example):

# apradar -i ath0

The AP Radar main screen appears, as shown in Figure 3-4.


Figure 3-4. AP Radar main screen


AP Radar shows all access points
that are in range. Almost every field on the screen is either
clickable or provides you with information when you hover the mouse
over it.

To associate with any of the access points shown under Access Point
List, simply click on the name of the access point. By default, AP
Radar not only associates your wireless card with the selected AP,
but it runs dhclient to obtain an IP address via
DHCP.

This and one other option can be set by clicking on the red symbol at
the top of the AP Radar screen. You can set two options:

Ping default gateway


This monitors the gateway that you receive from DHCP. When it does
not receive a response from a ping after more than a second, AP Radar
assumes that the gateway is out of range.


Run dhclient on associate


This allows you to specify whether you want AP Radar to obtain a DHCP
address for your PC after it associates with an access point. Turn
this off if you need to use static addressing.



In addition to displaying the SSID, mode, and channel and signal
strength for each access point, AP Radar also displays whether WEP is
enabled by displaying the warchalking symbol for the network. See the
later Section 3.2.5.


3.2.3 Wardriving


Back in the good
ol' days of hacking,
wardialing
was (and still is) the act of having a computer use a modem to dial
phone numbers from a list or mathematically step through all possible
numbers in a telephone exchange. Malicious hackers noted each line
that had an answering modem and went back to those numbers to find
systems that could be compromised.

With the proliferation of notebook computers, handheld computers, and
wireless network cards, the term wardriving has
been coined. When you wardrive, usually a two-man team takes off: one
driving and the other handling the wireless scanning. In dense urban
areas, a wardrive can locate hundreds if not thousands of active
SSIDs.

With some added equipment such as external antennas and a GPS
receiver, wardrivers can log each wireless network and place them on
a physical map. http://www.wifimaps.com is just one example
of a collaborative effort to place wardriving maps from all over the world in
an online database. Kismet (discussed previously) makes an excellent
tool for wardriving, and it interfaces with GPS systems. See Chapter 10 and the Kismet documentation for details.

People wardrive for different reasons. While many people do it simply
for enjoyment or for the technical knowledge gained, there are also
those who have more illicit purposes in mind. Some wardrivers are
specifically out there looking for insecure networks that can be
compromised for various purposes.

Wardriving may not be legal in your area. While it does not appear to
be illegal in the United States, there are many countries where it is
considered a crime.


3.2.4 Warflying


In the same vein,
warflying
is conducted by those lucky people who can afford to rent a plane for
a few hours or who actually have their own plane. Warflyers generally
need external antennas to pick up wireless networks below the plane.

If you think this practice sounds too far-fetched to be true, Google
for the phrase "warflying".
You'll be surprised at how many people do this.


3.2.5 Warchalking


During the Great
Depression, many people in the United States were homeless because of
economic conditions. Tramps and hobos traveled the country looking
for work and food. Due to scarcity of work, hobos were not welcome in
many places. Over time, hobos devised a set of logos that could be
written in chalk or stone, or carved in trees near various houses,
restaurants, and other places. These logos could communicate
everything from "free food" to
"you will be beaten."

You can visit the following web sites for more
symbols used by
the hobos:

http://www.slackaction.com/signroll

http://sedaliakatydepot.com/hobo


Matt Jones, an
Internet product designer, operates a web site (http://blackbeltjones.com)
that serves primarily as the Londoner's online
resume and portfolio. In 2002, Jones combined the practice of using a
sniffer tool to detect a wireless network with the
hobos' set of logos to come up with the symbols for
wireless networks (see Figure 3-5).


Figure 3-5. Warchalking symbols


Using these symbols, wireless users can discover if there is an
available wireless network for their use. He was inspired by
architecture students "chalking up the
pavement" on his way to lunch. During a lunch, Jones
and a friend, who had recently been discussing hobo signs, called
their idea warchalking. You can learn more at http://www.warchalking.org.


/ 100