Skip to end of metadata
Go to start of metadata

Today, Monday July 3, 2006, in the morning, the faculty network was disturbed. The reason was a wireless access point (WLAN AP) installed by a user, and not configured properly. IRC-IT personnel found out about this, located the malicious device quickly, and restored faculty network operation by shutting the rogue access point down.

Preventing infrastructure interference is one of the good reasons, why it is not allowed at IUB to setup own WLAN access points. Impairment of the work of others is specifically forbidden by the General Policy Governing the Appropriate Use of Computer Resources.

Installing WLAN access points is a task of IRC-IT. Contact IRC-IT's Service Desk for Faculty and Staff if you require a WLAN access point.

4 Comments

  1. A technical question about having "private" WLAN AP's:

    I know that there are a few reasons why having them could potentially disrupt network operations. Just not sure what the exact details are. Network address translation as well as DHCP services running on the AP will in effect shield the end-user from the net side of the AP, making it impossible to check which MAC address is causing the trouble. There is also the security side of it, where it becomes possible to have access to otherwise closed and protected sub-nets (such as the student network in the colleges). If one were to disable DHCP and NAT on the AP, hide the SSID (by not allowing the SSID name to be broadcast), and require strong encryption on the wireless network, and force MAC address restriction, wouldn't these potential problems be avoided? Sniffers exist for checking hidden networks, and faking a MAC address is possible, but someone would still have to get through the wpa key. So what I'm really asking is what exactly is the main reason why it is not allowed to set up WLAN APs on the current lan? Thank you,

    Serkan

    1. The main reason to disallow rogue WLAN APs is the trouble they are causing on various levels: starting from channel interference, errorneous configuration of DHCP, DNS, bridging, leading to networks going down (like the faculty network in the current case, or the student network on the start of each semester), confused users ("why is there a network called **** constantly popping up during my presentations?", "The university's home page can't be found, the network is poor!"), legal issues of abuse of our network from outside the university's premises, up to security issues of broadcasting confidential network data through the air (faculty, admin) and potentially outside the premises, or confused users falling into a trap ("I have entered my password at least twenty times, it is still not working!" "Which network did you try to login to?").

      Yes, all this has happened (except, I don't know of the last example) and is generating unnecessary confusion, work, and disruption of regular services.

      Interference with infrastructure (WLAN included) is not permitted to protect the community from harm while keeping the effort manageable.

      1. This thread is more about reliability and availability than security (re: security, not about SSID broadcasting but enabling access in the first place).