Subject: Re: [NEXTEL-1] Wireless Access: Warchalking

From: [email-masked]
Date: Wed, 8 Jan 2003 09:00:36 EST

No, it's an HP.  But the firmware download's a great thought.  I will try 
that.  Thanks.

Alan

In a message dated 1/8/2003 7:20:47 AM Eastern Standard Time, 
[email-masked] writes:

> Is it a Compaq?  My dad had a problem with the D-Link product and found 
> there was a Softpaq solution for it, a freebie to download and flash the 
> BIOS.  I had a problem with the Linksys where certain machines would flake 
> out.  I would flash the Linksys card with a new rev for firmware, and the 
> problems evaporated.

---

From: Greg Smith <[email-masked]>
Date: Wed, 8 Jan 2003 08:57:32 -0500

Maybe of interest to the topic - Wireless Access. It's not definitive, was
written just to
provide some thoughts at that time for ICT Security Managers.
- Greg Smith

Wireless LANS
----------------------
Wireless LAN security risks - general observations
23.03.2002

The hot topic at the moment is about  Discovery - Offer - Request -
Acknowledge (the acronym DORA 
maybe used). It  is the process involved for a wireless terminal attempting
to gain access to a 
wireless LAN.

Wireless LANs may use DHCP (Dynamic Host Configuration Protocol). DHCP
provides the means 
for configuration of IP addresses dynamically, and regardless of location,
this process 
has also been termed active lease, operating on the principle of
"expiration date", which 
automatically allows re-allocation of IP addresses that are no longer in
use. This is meant in
terms when one user finishes with the IP address it can be assigned to
another user immediately.
The security concerns surrounding IP allocation increase where there can be
a perceived threat of 
an intruder using the system resources having scanned the radio perimeter
for unprotected DHCP IP 
addresses allocation and security experts have identified that unprotected
wireless LANs are vulnerable
to this. Experts carried out tests to substantiate the claims they were
making. 

Take control of "permissions" and "restriction" for access through adoption
of Client and Server key and a 
Message Authentication Code (MAC) algorithm. It true to say that guidance
standard RFC2131 did not 
include an authentication solution, but in 2001 RFC3118 Authentication for
DHCP Messages was released
to include this matter. 

The abstract for this document states "This document defines a new Dynamic
Host Configuration Protocol
(DHCP) option through which authorization tickets can be easily generated
and newly attached hosts with 
proper authorization can be automatically configured from an authenticated
DHCP server. DHCP provides
a framework for passing configuration information to hosts on a TCP/IP
network. In some situations, network
administrators may wish to constrain the allocation of addresses to
authorized hosts. Additionally, some 
network administrators may wish to provide for authentication of the source
and contents of DHCP 
messages."

Okay, so what observations can be highlighted which ICT security managers
can introduce to reduce risks? 
Remember the rule of thumb - don't implement unless you know what you are
doing.

Basic Observations:
- Remember that non-compatibility can cause vulnerability. Thoroughly
peruse technical specs.
- Obtain security guidance from your supplier - get your supplier to
identify which security techniques
they have researched and recommend and ask why it provides better security
than other techniques. 
- Obtain the suppliers security manual and, yes, you do have to read it
- Cross check the use of  wireless network interface cards for
computers/laptops etc  (compatibility issues)
- Identify remote wireless bridges (wireless access points) - can serve as
internal security devices eg
read only addresses encoded into LAN adaptors (i.e. MAC addresses) making
spoofing difficult. 
- when deploying Nodes (usually hidden nodes) do consider carefully power
capture, radio interference
sources and obstructions to signal propagation - can cause external leakage
and information might escape.
- determine the perimeter of the radio coverage - no surprises when you
detect your wireless LAN messages
outside the building at pavement level. Also consider possibly that the
adjacent buildings might detect your 
wireless LAN messages.

And here's some more observations about advanced issues:  
1. The management of IP addresses is required to be worked out in advance
in order to achieve, for example 
balancing system resources -v- anticipated traffic flow. Balancing being
the operative word. 
2. Consideration whether the wireless LAN system supports roaming and
likely areas of vulnerability.
3. The alternative to multi-channel networks is independent networks that '
usually ' do not support roaming. 
DHCP can still apply but predicating traffic flow and determining it from
historical activity can assist identify
unusual traffic patterns.
4. Take control of "permissions" and "restriction" for access through
adoption of Client and server key
and a Message Authentication Code (MAC) algorithm. It true to say that
guidance standard RFC2131 did 
not include an authentication solution, but in 2001 RFC3118 Authentication
for DHCP Messages was released,
which deals with the omission in RFC2131. 
5. Do consider encrypting all data transmission via the wireless link.
6. Close the network to all nodes that have not been programmed with
correct network identification.
7. Restrict access within a wireless LAN by listing only those nodes that
are allowed to transmit data.
8. Implementing passwords in network operating systems
9. Infrared LANs can be at risk but higher probability risk would be an
internal threat.
10. Consider whether their are possible uses of TIM and receiver activated
for tracing activity
11. Deploy WEP, but not as the single and only solution.
12. Implement terminal password login.
13. Implement policy of login/log out and transmit confirmation
14. Avoid shared wireless terminals amongst users but if unavoidable only
one login at a time
from terminal each user must login separately.
15. Avoid users sharing a single login.
16. Monitor all logins and MACs
17. Monitoring traffic on the backbone.

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

---

From: [email-masked]
Date: Thu, 9 Jan 2003 08:45:34 EST

In a message dated 1/9/2003 1:00:53 AM Eastern Standard Time, 
[email-masked] writes:

> I guess mail order here you come. How did the Siemens unit work? I guess it 
> did not.
> 

I didn't buy it, since it was designed to operate off the router, not the 
client.  I guess I could try it from the other end, anyway, but I've been 
kinda busy getting my laptop configured to run around again.......