About security- attached devices?

My home network is secured by WEP and MAC authorizations.

When in the settings I can see a list of the attached devices. My
desktop and two laptops show up by computer name and MAC address.
That's it.

If someone was able to hack into my network, would their computer
always show up as another attached device to let me know that someone
was able to get in?

TIA

O <(E-Mail Removed)> hath wroth:

>My home network is secured by WEP and MAC authorizations.

That's like saying your front door is secured with duct tape and
balling wire.

>When in the settings I can see a list of the attached devices. My
>desktop and two laptops show up by computer name and MAC address.
>That's it.
>
>If someone was able to hack into my network, would their computer
>always show up as another attached device to let me know that someone
>was able to get in?

If you have MAC address filtering enabled, a successful attacker would
show up as one of your laptops MAC addresses. You would not know the
difference between the attacker and your laptops.

An unsuccessful attacker, who did not bother to spoof the laptop MAC
address, will not show up at all since they cannot connect.


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Sun, 02 Jul 2006 12:02:34 -0700, Jeff Liebermann
<(E-Mail Removed)> wrote:

>O <(E-Mail Removed)> hath wroth:
>
>>My home network is secured by WEP and MAC authorizations.

>
>That's like saying your front door is secured with duct tape and
>balling wire.

Best I can do under the circumstance. Can't use WPA. One of the
laptops is an old Win95 and I'm lucky it can connect at all.

>>When in the settings I can see a list of the attached devices. My
>>desktop and two laptops show up by computer name and MAC address.
>>That's it.
>>
>>If someone was able to hack into my network, would their computer
>>always show up as another attached device to let me know that someone
>>was able to get in?
>
>If you have MAC address filtering enabled, a successful attacker would
>show up as one of your laptops MAC addresses. You would not know the
>difference between the attacker and your laptops.
>
>An unsuccessful attacker, who did not bother to spoof the laptop MAC
>address, will not show up at all since they cannot connect.

Are you saying that if I did not have MAC address filtering enabled
then I would know if someone else connected by having an unknown
attached device listed? In other words is it better not to have MAC
filtering enabled?

O <(E-Mail Removed)> hath wroth:

>Best I can do under the circumstance. Can't use WPA. One of the
>laptops is an old Win95 and I'm lucky it can connect at all.

W95 is generally NOT supported by most current wireless devices.

>>An unsuccessful attacker, who did not bother to spoof the laptop MAC
>>address, will not show up at all since they cannot connect.

>Are you saying that if I did not have MAC address filtering enabled
>then I would know if someone else connected by having an unknown
>attached device listed? In other words is it better not to have MAC
>filtering enabled?

Disclaimer: I are not a security expert.

What I'm saying is that even with MAC address filtering enabled, a
fairly unsophistocated hacker can easily spoof one of your laptops MAC
addresses and you would never know it. Using Kismet, I would find
your access point, highlight the SSID or MAC address, hit "C" to show
connections, and I have a list of wireless clients MAC addresses that
are connected to your access point. One the hacker has your laptop's
MAC address, his attack will appear to be coming from this MAC
address. You'll never notice anything wrong because there will not be
any "new" MAC addresses listed.

You might want to look at Airsnare:
http://home.comcast.net/~jay.deboer/airsnare/

As for whether it is "better" to have MAC filtering or not, I don't
really know. I think it causes more grief than good. The problem
happens every skool vacation and at the end of the skool year. The
kids come home from college with their laptops and can't connect to
the family wireless router because some security expert enabled MAC
filtering and their laptops are not on the approved MAC list. The
same problem also appears when friends, relatives, vistors, etc comes
to visit with their laptops or PDA. Eventually, I get asked to
disable MAC filtering which I've done on almost all my customers
access points.

There is a school of thought that subscribes to "security by
obscurity" and the "obstacle course" method of applying it. In
theory, the more obstacles placed in the way of the hacker, the better
the security. Whether this works for your situation largely depends
on what you're trying to protect, what hardware you have available,
and whom you expect too break in. I have no opinion one way or the
other.

See the FAQ at:
http://wireless.wikia.com/wiki/Wi-Fi#Wi-Fi_Security
for some references and reading.

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Jeff Liebermann <(E-Mail Removed)> writes:
> One the hacker has your laptop's MAC address, his attack will appear
> to be coming from this MAC address. You'll never notice anything
> wrong because there will not be any "new" MAC addresses listed.

I was wondering about this myself for the past few days. I believe it
would be possible for a sophisticated probing device to fingerprint
the OS of the attacking wifi client. Openbsd has such a fingerprint
probe built into the pf (packet filter) utilities. I believe there
are standalone versions too. In addition, Netcraft also runs one for
determining what OS a web server is running. So in summary, a not so
sophisticated attacker might well give their presence away by
attacking using the wrong type of OS.

> There is a school of thought that subscribes to "security by
> obscurity"

Ah, the rhythm-method of network security. ;-) (It works best when
used in conjunction with real protection.)

-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/

"Wolfgang S. Rupprecht"
<wolfgang+(E-Mail Removed) .wsrcc.com> hath
wroth:

>Jeff Liebermann <(E-Mail Removed)> writes:
>> One the hacker has your laptop's MAC address, his attack will appear
>> to be coming from this MAC address. You'll never notice anything
>> wrong because there will not be any "new" MAC addresses listed.

>I was wondering about this myself for the past few days. I believe it
>would be possible for a sophisticated probing device to fingerprint
>the OS of the attacking wifi client.

Certainly it's possible. The problem is that the bulk of the IDS
systems operate at the IP level. However, this is all happening at
the MAC layer. The excessive number of ARP requests will show up on
the IP level, but not disassociation and deauthorize packets. A
suitable defense would be similar to the SYN flood fix, where the
device determines what constitutes a "normal" level of requests and
drops everything above a preset level. With an exponential backoff
algorithm, it should seriously slow down ARP probes and multiple
identical associate and disconnect packets.

>Openbsd has such a fingerprint
>probe built into the pf (packet filter) utilities.

IP level again. That might work for ARP probes, but not for MAC layer
stuff. If the wireless device was in the same box as the server
running OpenBSD, then I guess it would be possible to probe the
wireless interface to look for exploits.

>I believe there
>are standalone versions too.
>
>In addition, Netcraft also runs one for
>determining what OS a web server is running. So in summary, a not so
>sophisticated attacker might well give their presence away by
>attacking using the wrong type of OS.

Sure, assuming that the LAN administrator maintains a database of all
authorized wireless devices. It could be added to the ever growing
LDAP database. OS fingerprinting is also incredibly easy to spoof and
emulate. Even if it worked, using RADIUS authentication would do a
better job and is probably easier to maintain. Back to IDS please.

There is some work on wireless IDS. See:
http://www.snort-wireless.org
The project appears stalled (not sure). I couldn't find anything that
even mentions active scanning.
http://www.snort-wireless.org/docs/usersguide/
On the MAC layer, it will apparently detect management and control
frame types:
Valid Management Frame Subtypes
STYPE_ASSOCREQ
STYPE_ASSOCRESP
STYPE_REASSOC_REQ
STYPE_REASSOC_RESP
STYPE_PROBEREQ
STYPE_PROBERESP
STYPE_BEACON
STYPE_ATIM
STYPE_DISASSOC
STYPE_AUTH
STYPE_DEAUTH
which include the necessary disassociate and deauthorized packets. The
rest would be just writing rule sets and intrusion patterns. The
catch is that there has to be some way to deliver this data to the
IDS. There's no easy way to do that using syslog or SNMP. That means
this wireless IDS is only useful with a server running snort-wireless
and that has a built in wireless device running an access point
emulator.

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Jeff Liebermann <(E-Mail Removed)> hath wroth:

>There is some work on wireless IDS. See:
> http://www.snort-wireless.org
>The project appears stalled (not sure). I couldn't find anything that
>even mentions active scanning.

It's not stalled. Apparently, snort-wireless patches have been rolled
into the main Snort distribution. I haven't checked to see if they
are actually there, but that's what one web page suggests. Reading
the docs, the wireless IDS requires that the AP be part of the server
running Snort. It also mentions that they work on Linux based
wireless routers, such as WRT54G.

Article on wireless IDS which includes deauth and disassoc examples.
http://i.cmpnet.com/nc/1612/graphics...nment_file.pdf

There are other related papers at the bottom of:
http://www.snort.org/docs/


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Jeff Liebermann <(E-Mail Removed)> writes:
> Certainly it's possible. The problem is that the bulk of the IDS
> systems operate at the IP level. However, this is all happening at
> the MAC layer.

I wasn't thinking that the OP with the MAC filtering was going to be
able to keep a determined intruder out. I figured they'd be in in no
time and the question was only how to demonstrate that the MAC didn't
belong to the computer he was expecting.

Thanks for the info about the management frames. I've been meaning to
learn more about that layer. Yesterday while using my laptop in the
back yard I got dissassociated from the AP twice and couldn't
reassociate for an extended period of time. I need to figure out what
that was about. (linksys wrt54g/openwrt/wpa2-psk and fedora-core
5/wpa_supplicant/wpa2-psk. Wpa_gui clearly showed that I wasn't
associated and it was "scanning", but failed to lock onto my ssid
without wpa_supplicant being restarted. It "feels" like a bug in
wpa_supplicant. I clearly need to learn more about this level of
things so I can track this down.)

-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/

Jeff Liebermann <(E-Mail Removed)> wrote:

> O <(E-Mail Removed)> hath wroth:
>
> >My home network is secured by WEP and MAC authorizations.
>
> That's like saying your front door is secured with duct tape and
> balling wire.

Well. Most front doors are just that, are they not? Burgular prevention
is not a question of what lock you have on your front door, but of
social control.

On Sun, 02 Jul 2006, in the Usenet newsgroup alt.internet.wireless, in article
<(E-Mail Removed)>, Wolfgang S. Rupprecht wrote:

>Jeff Liebermann <(E-Mail Removed)> writes:
>> One the hacker has your laptop's MAC address, his attack will appear
>> to be coming from this MAC address. You'll never notice anything
>> wrong because there will not be any "new" MAC addresses listed.

Not specifically true. If you know your lapdog is turned off, you might
notice that the router/firewall/what-ever is talking to it - that might
get your attention. The other case is if your laptop is NOT turned off.
Then, it should start sending TCP/IP 'RST' packets back to the source
that the cracker is attaching to - "I'm not talking to you, why are you
sending me this crap?" Use a packet sniffer, such as 'tcpdump' or
'ethereal' or similar, and manually change one of your systems to have
a duplicated MAC and IP address - you'll see the confusion.

>I was wondering about this myself for the past few days. I believe it
>would be possible for a sophisticated probing device to fingerprint
>the OS of the attacking wifi client.

[compton ~]$ whatis nmap p0f
nmap (1) - Network exploration tool and security scanner
p0f (1) - identify remote systems passively
[compton ~]$

It's not really that sophisticated - it's just detail oriented. On the
other hand, do a google search on the term "defeating O/S fingerprinting"
to see how things battle back and forth.

>Openbsd has such a fingerprint probe built into the pf (packet filter)
>utilities. I believe there are standalone versions too.

If that is the code by Mike Frantzen, it's similar to p0f. The README
file that comes with p0f lists a fair number of other fingerprinting
tools and discusses the technique. Fyodor Yarochkin (not the Fyodor of
nmap fame) and Ofir Arkin have also published some decent material on
active fingerprinting using subtleties in ICMP.

>In addition, Netcraft also runs one for determining what OS a web server
>is running.

While passive and active fingerprinting is more complicated, I wonder how
much of that is simple banner reading.

>So in summary, a not so sophisticated attacker might well give their
>presence away by attacking using the wrong type of OS.

You'll notice that most of the users are running some variant of windoze.
While it is often possible to differentiate between versions - indeed within
patch levels, it's also not a sure fire thing.

>> There is a school of thought that subscribes to "security by
>> obscurity"
>
>Ah, the rhythm-method of network security. ;-) (It works best when
>used in conjunction with real protection.)

I dunno - the zombies have been beating the sh!t out of my port 22 and
not finding anything, mainly because my sshd isn't listening to that port.
It's actually listening to some port above 1100 to get beyond the average
port scanner. Add to that a non-obvious username, and you've stopped the
zombie and average skript kiddiez cold, and that's before they even get
to the authentication mechanism.

Old guy