How to prevent unauthorized access into network

What hardware do you have? Switches/AP's/Wireless controllers etc?

You can use Mac Address reservation found on most routers and also available in Windows Servers DCHP settings.

With this in place it may be a little harder to manage your network but the upside is that it also helps with inventorying your network.

Static IP's are easy to assign, and sniffing the network is any easy to figure out one to use, no IP is necessary to sniff the network. PacketFence/FreeNAC and the others I linked to above, take most of the work out of managing Mac-address's, in addition, if someone were going to sniff the network as soon as they plugged in, the swtich saw physical (layer-1) connection, the port would be placed in a vlan that contains only other isolated hosts with no route to anywhere, assigning and sniffing ip address's will do no good there. In addition, devices found to be setting off a Snort alert for instance, can be automatically sent to isolation and no matter where they plug in the network their port will be isolated.
Nothing is fool-proof. If I were a hacker, and I had a box that was permitted to access the network, if I added a second network card to a PC for instance, I could use XP's ICS or *nix's NAT services to allow a rouge AP to pass traffic in and out because the switch would only see the mac from the Nic that plugs in the switch, not the mac's of everything behind it, such is the nature of nat.
Additionally, If I were to unplug a printer in the network, clone it's IP and Mac for my AP, the switch would know no different. 99% of the network printers I've encountered allow anyone who wants to, to print out it's current configuration. If I really want to be stealthy, I plug the printer in my second nic and fwd printer traffic to it.
-rich

It does require coordination with the network team to impliment 802.1x, which is built-in and enabled by default on XP and greater M$ os's. The app's I've linked to have varying degrees of difficulty, the StillSecure product is free, it's a VMWare image, pertty easy to setup and use. Also there are consulting services for many NAC solutions.
I also don't know the size and the scope of the network, but I'd hate to manage a single 48 port switch by manually white-listing Mac's, but I'm lazy so it could be me. Depending on how a switch makers uses mac-address white-lists, the mac's might have to be associated with a particular port and not just be read off a list.
Your also correct, security policies must come first and foremost, Sans has some great templates to start with: http://www.sans.org/resources/policies/#template and your network design should alllow you to enforce said policies effeciently.
There is no 100% way as I've stated above to keep a rouge AP off the lan, but you can implement 802.1x or other mac address authorizaion mechanism to help.
http://207.46.16.252/en-us/magazine/2008.02.cableguy.aspx
http://technet.microsoft.com/en-us/library/cc512611.aspx
http://www.sans.org/reading_room/whitepapers/firewalls/wired_802_1x_security_1654?show=1654.php&cat=firewalls
-rich

Rich, I'm wondering why you do not believe rogue scanner would be able to detect a rogue AP that is being properly firewalled?  It does numerous tests to determine what the newly connected device is, much like OS fingerprinting.  "RogueScanner scans your network devices and collects device classification information such as IP and MAC address, what TCP and UDP ports are open, how the devices respond to common network requests, and the DNS or NetBIOS name used by the device."  How the device responds to "common network requests" is the one to look for and the specialty of the fingerprinting.  However I agree that your solution would be better to employ for a prevention solution, I don't believe that this software would be rather useless for detection of such a device.  After all, if they know enough to know how your typical ap responds to certain normal and malformed packets and is able to manipulate them all to come across as some other device (MAC would have to be changed anyway, bye whitelist), while still providing functionality as an ap, I do not believe any other detection solution would work against someone setting a rogue ap up.  Just curious as to why you figured that.

You could detect a new AP in range of a scanner, however, you wouldn't necessaryly know if it was plugged into your network if the firewall drops all packets, including icmp. If a device has no responses, it can't be finger-printed. There is the wifi part of a AP one could detect the proxmity of, but again unless you audit the mac-address's on your switches, or have a traffic sniffer, you'd never know it was on the physical lan. IPTables, even windows XP (and beyond) can be configured to drop any non-stateful connection. A stateful connection is one made from the PC to the outside, which will then allow those remote ip's back in, but even while that's going on, a scanner won't detect it if the FW is doing it's job.
You don't need to have any ports open on your PC to allow traffic in through your firewall, scan your home IP using GRC's Shields Up and see what ports are open if any.
http://en.wikipedia.org/wiki/Stateful_firewall
-rich

Even though I'm searching Google.com on port 80, no scanner, and not even the server I'm connected to in google could scan my PC and get a response. TCP is more complex than that, and the same holds true for many UDP protocols. You'd want to prevent the physical Lan interface of a WAP being plugged into the network, it's best to have 802.1x or other from port access to accomplish that goal.
-rich

If the firewall dropped all packets sent to it, I would believe that would raise a whole lot of red flags.  After all, dropping packets isn't really stealth, rejecting packets is. Not only that, let's take a look at TTL values when sending a request to nothing in comparison to sending requests to a device behind a firewall.  Roguescanner live discovers any new connection, so I would imagine that would be a packet sniffer looking for anything responding to an arp request from the router.  I haven't exactly looked at all of the source code behind rogue scanner, but if I were to fingerprint a device on a non-ipsec ipv4 network, I would create a packet that comes from all attached network devices and see if there is any difference in the responses (UDP, I'm not going to worry about ISN's).  Also, my fingerprinting would definitely include banner grabbing on both ssh and http if the device is unknown.  Especially in relation to detecting access points.  These are just a couple of examples for common fingerprinting techniques I would expect to see in fingerprinting an access point.  However, this answer of rogue scanner doesn't work also seems to be self-defeating.  This is something I see often in the security field.  If a person asks a question, like how could I detect it (given that the question was detect OR prevent), the person throws out that this is how you could bypass any detection methods, successfully evading the question asked.  But, again, I agree that the obvious choice should be a preventative measure and not a detection, however either one is not always possible, thus why I supplied both.

I'm only going to de-rail the discussion for a moment.
I don't think you understand networking well enough yet. If I ping sweep 1.2.3.0/24, that's a typical 255 host subnet (255.255.255.0 mask) and I get replies from 14 host's, that doesn't mean there are only 14 hosts, it means only 14 replied. Regardless of protocol used to scan, even if a host doesn't reply to icmp, it might still have port 80 open. So I scan with icmp also look for port 80 header replies, now I see 16 host's, meaning there are at least two more hosts on the network that are replying to data I'm sending out. If I check the mac listing on the switch and see there are in fact more devices than that I can assume that either I haven't scanned all the possible ports, or the host's don't reply to me even if I did scan all 65535 ports.
We setup ACL's all the time for one-off customers, so customer_x from ip 4.5.6.7 is allowed to see port 80 open on our IP of 6.5.4.3, but if anyone else in the entire world scanned port 80 for IP of 6.5.4.3, they would receive no reply and could never know if there is a host there or not, unless our host sent them traffic first.

Most wifi devices have a setting to allow remote administration or local administration. If you disable remote, then port 80 or 443 is turned off for anyone on the wifi side, but anyone with a physical wired connection to the WAP can see port 80 open. Some go further, allow remote admin, but only from ip.ip.ip.ip that I specify, so only the static IP I've reserved and set aside for myself can see port 80.

The point is, if I plug a wap into your lan, you scan using your scanner, it won't see it because it's firewalled and drops all incoming traffic. The only way you'd know it was there is from sniffing traffic that the WAP itself initiated, not traffic you sent to the wap, or by auditing the mac's on your switch ports. Rejecting packets with a RST packet or host-unreachable is actually a response. Ignoring packets is like there is no host there at all. If the scanner you mention discovers new connections it must be based on passive sniffing and or has layer 2 access to a switch, or you see a link light where there wasn't one before. It's the lan interface of the wap you need to detect, not the wifi side. Further the WAP's I use disallow each wifi client to see one another, so scanning for other hosts with wifi address's returns nothing, the wap drops the packet like nothing was there at all.

Your also correct I think we've covered the solutions as best we can, nothing is 100% but mac-address monitoring/listings and 802.1x protocols are best suited for the task.
-rich

That's what I was saying.  The fingerprints I declared were only two examples.  The banner grabbing and other fingerprinting techniques are obviously not going to be fool-proof, that's why any fingerprinting service must conduct several tests.  I was thinking that "rogue scanner", seeing as it live discovers targets, would be passively sniffing the network for ARP requests going from router (a set ip)->device.  That would be the best way, in my mind, to identify if a new device is going to be attached to the network.  Having said that, the device not responding to ICMP would raise the first red flag.  As you know it exists, but it's ignoring your requets.  Thus, the fingerprint technique of finding this would be dropped packets vs. rejected packets (sign of a truly closed port).  This would show in the TTL as the firewall has to make a decision whether to allow or drop the packet before it reaches the host.  Thus the TTL value would be increased if the user is behind a firewall over if the device in question does not actually exist.  You could find this out by constantly conducting tests on your other devices that are connected and then comparing them with the device you know exists, yet doesn't respond to your ping (or other icmp) requests.  

You only catch errant packets or broadcasts (like arp).TTL's do not increase for layer 2 devices, and firewalls/switches/hubs/bridges fall under that category typically. Software firewalls certainly don't decrement the ttl, and no hardware firewall I've used does. Relying on arp or errant packets is one way, but would take much more time (too much probably). I've not tested the rouge scanner, if it does the passive monitoring, it would in fact work.
-rich

I thought that dropped packets increased the time it took to get a timeout exceeded message from the dropped packets over that of a reset when the port is actually closed?

Nevermind, what I said above doesn't make any sense.  I was thinking of getting timeout messages from a closed port via UDP and mixed a bunch of things up along the way in my head.  Sorry about that.

I don't think http://www.experts-exchange.com/Security/Misc/Q_24548181.html?cid=1573#24818850 answers the original question(s) at all.

TurboBorland's first reply, (http://www.experts-exchange.com/Security/Misc/Q_24548181.html?cid=1573#a24790431), richrumble's first reply (http://www.experts-exchange.com/Security/Misc/Q_24548181.html?cid=1573#24793861), my reply (http://www.experts-exchange.com/Security/Misc/Q_24548181.html?cid=1573#24797873), and ABLComputers' first reply (http://www.experts-exchange.com/Security/Misc/Q_24548181.html?cid=1573#a24803014 - the policy against it may not deter everyone, but it IS another prevention method) all address Q_24548181's queries, though.  :-)

My recommendation is #3, and per the full links (else they could not be followed from the CS zone where the objections end up) in my previous message (http:#25203531),

http:#24790431 - 150
http:#24793861 - 150
http:#24797873 - 100
http:#24803014 - 100

The first 2 address prevention and detection; the latter 2 only prevention.

Of course, feedback from the member as to their actual resolution of the problem would not be unwelcome by me, even at this stage of the 'cleanup' process. :-)