About security- attached devices?

O hath wroth:

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

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.

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.

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 hath wroth:

W95 is generally NOT supported by most current wireless devices.

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:

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:

some references and reading.

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.

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

-wolfgang

"Wolfgang S. Rupprecht" hath wroth:

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.

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.

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:

project appears stalled (not sure). I couldn't find anything that even mentions active scanning. 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 hath wroth:

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.

There are other related papers at the bottom of:

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

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.

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.

[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.

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.

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

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.

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

snipped-for-privacy@painkiller.example.tld (Moe Trin) hath wroth:

Well, ok. If my intrusion detection system has a built in motion detector that can detect if I'm in the house, perhaps using my physical presence as an authentication method might work.

I've done this a few times and it's survivable. I vaguely recall some excess traffic but nothing fatal. However, I haven't looked at the traffic with Ethereal. Sounds like a fun thing to do. Tomorrow, maybe.

If the other laptop is turned on, I know of at least 2 ways of removing the laptop from the WLAN. I've only tried one and it works. If you want details, email as I don't want to publicize exploit details. Note that these methods do NOT require a completed connection to the AP in order to generate the necessary IV's that can be used to deduce the WEP key. In other words, it's not necessary to spoof the MAC address in order to do an active attack. Spoofing the MAC address is only necessary to actually connect once the WEP key is deduced.

However, any of these methods are certain to be noticed by the laptop user. It will be disconnected, crash, or otherwise act weird. Few such laptops are always on. If anything, the battery saver will shut it down if left on for extended periods.

On Sun, 02 Jul 2006 12:02:34 -0700, Jeff Liebermann wrote in :

Shades of Homeland inSecurity. :)

I'd personally not even say it's that good -- more the level of leaving the front door latched but not locked.

On Mon, 03 Jul 2006 19:23:36 -0500, snipped-for-privacy@painkiller.example.tld (Moe Trin) wrote in :

MAC spoofing is typically combined with a DoS attack on the spoofed client.

You can never know that you haven't been compromised.

On Mon, 03 Jul 2006 20:58:01 -0700, Jeff Liebermann wrote in :

Not necessarily:

• Quite a few low-traffic servers run on old laptops because power consumption is low and the built-in battery is a cheap and effective UPS.

• I've also seen many normal laptops with power management disabled.

• The typical laptop user assumes the machine is acting up as usual, and either reboots or abandons it. Almost never would this be recognized for what it is.

Thats absurd. Burglar prevention is a matter of both. However leaving your door open is certainly not going to reduce it.

Example - I have a central authentication service, so there is one passwd file, and it keeps track of whether I (or any other authorized user) is logged in and from where - much as you'd see with the Unix 'who' command output. Logging in takes about 25 seconds from starting to enter the username until the desktop is up, so I don't stay logged in when I'm not there (at work, the login sequence takes almost a minute, so I tend to log in in the morning, and out at night, while when away from the desk, the screen saver is password protected). There are quite a number of other tricks that can be used.

Someone in a non-technical Usenet group recently reported a mechanism supposedly used by CHINANET on their perimeter to block "undesirable" material from "outside". If you aren't aware, in addition to being the major backbone in China, they are a part of the People's Liberation Army.

I suspect I already know about them. There's probably more if the laptop is running windoze.

Very true. But as Wolfgang mentions, the average attacker isn't all that swift, any more than the average criminal. The local news here showed a surveillance camera recording of a recent robbery. Our hero gets in line, and when the customer in front of him is through with the teller, this klown then dons his mask, and goes into the "this is a stick-up" routine. He apparently figured it wouldn't be a good idea getting in line with the mask on... which probably is correct, but... While you certainly can't count on it, the average attacker is going to be making similar detectable whoopsies.

Old guy

The word "sophisticated" is context sensitive. In the context of a group where folks seem to run WEP and hide ssid's for security, fingerprinting OS's is relatively sophisticated. ;-)

Oh, I'm sure they use all the cheap kills they can get. They do have trouble telling openbsd and netbsd apart, so I assume they are trying to characterize the IP stack in some way and the similar code-base of the two OS's keeps them from deciding which strain it is.

Tell me about it. I've run ssh with without password authentication enabled for many years now. I'm willing to risk them guessing my rather long RSA key. If they are lucky 10^308 guesses should do it. If not, twice that. The problem is the cost of starting up the ssh tunnel was substantial enough for me to notice on xload. I finally ended up tail(1)-ing the sshd logfile and adding any attacker to a pf hash-table filter by IP in realtime. Well at least my cycles are my own again.

-wolfgang

Welll... yeah, I'll give you that one. Most people are not even aware that the protocol headers exist, never mind that because there are quite different interpretations of RFC1122 et.al., there may be things to analyze.

Looking at the fingerprint data in various tools, unless you are using the 'scrub' mode in the OpenBSD pf code, the two have virtually the same flags and options set. They really are hard to tell apart at the packet level. Then you are left with banner reading - notoriously unreliable.

Unless you have authorized people connecting who can't figure out how to tell their client to use a different port, I _strongly_ recommend moving the server to a high port. As most of the "attackers" are zombie scripts or the usual 31337 skript kiddiez following some d00ds canned set of instructions, the idea of searching 65000 ports to _find_ the server in the first place eliminates all but specific targeted attacks. You can take it further by using port knocking - where an authorized user first sends a packet (_any_ kind of packet) to some closed port, and the firewall code then opens a completely different port for that IP address for a short time. You can take that further, and put traps on neighboring ports so that if (example) you hit port 13137 to open port 24185, but if the guy hits

2417x or 2419x before trying 24185, then 24185 is closed immediately.

I've always been nervous about automatic blocks. It's so easy to shoot yourself in the foot, especially if someone is spoofing IP addresses. The best idea is to have only needed services visible. If they can't connect, there's no reason to block them.

Old guy

I'm generally nervous about that too. The tcp three-way handshake gives me enough of a warm fuzzy that I'm not worried about blocking an undeserving party. I also have a failsafe that whitelists any IP that has correctly logged in via RSA or DSA.

If I move ssh it will probably be to port 80. Too many poorly though out filters in public locations seem to block all but web access.

Strangely I do scrub, but they still have problems. Maybe the fact that I used to run netbsd on that machine has them all confused.

-wolfgang

Yeah, it's nice using an Operating System where the sequence numbers are not predictable. None the less, I've seen people blackhole any address that even attempts a connection, and are unaware of spoofing until someone purely by chance spoofs an important number like their DNS servers or their favorite pr0n server. The upstream _should_ be blocking spoofs of local addresses at their perimeter, but RFC2827 and RFC3704 aren't a "STANDARD" (draft, proposed, or what ever - they're only BCPs). I've had two (local) ISPs in the past four years that did no filtering, and I left them as soon as I discovered this and that they couldn't spell RFC.

I whitelist a number of addresses ahead of any block rules.

The only time I've ever encountered this I also noted that they allowed

53/udp out as well, so I put a port knock requiring a hit asking for a WKS record (which the system ignored because there wasn't a DNS server on the port) and that opened 80/tcp for that source address. I didn't want to have the sshd accepting all and sundry on 80 (even though I was blocking all but their /16), and felt that the knock combination was sufficient.

My understanding is that scrub only normalizes packets from behind the firewall. The firewall box itself would still have "standard" settings, and the *BSDs look similar in that regard.

Old guy