WIDS/WIPS

introduction wireless intrusion detection system (wids) is a technology designed to protect wireless networks from unauthorized access it achieves this by monitoring traffic on the network to identify any suspicious activity that may indicate a security breach wireless intrusion prevention system (wips) employs a combination of techniques to detect and alert about intrusions in real time this system not only monitors but also takes action to mitigate rogue access points wired to the nile service block (nsb) for man in the middle attacks, denial of service floods, and any other threats to the wireless network, nile detects, alerts and sends a notification to the customer why are these systems important? wi fi presents a tempting attack surface for threats that can compromise data and network security while wi fi standards have evolved and become more secure with advancements in wi fi security protocols, hackers can still exploit a variety of vulnerabilities so, using wids/wips is essential for several reasons improved wireless security wids/wips are designed to detect and alert concerning any unauthorized activities on the wireless network in real time this is important to secure sensitive data and prevent unauthorized access to your network compliance some industries are required to use intrusion detection systems as a part of regulatory requirements wids/wips can help meet compliance regulations by providing a detailed audit log of network activity and potential breaches increased visibility wids/wips allows businesses to monitor their wireless networks visually this includes tracking access points, users, devices, and more, which is beneficial for identifying potential weak areas in the network and improving security measures proactive threat management using wids/wips means being proactive about threat management rather than reacting to security incidents after they happen, a wids can warn you of potential vulnerabilities and threats before they become security incidents protects from inside and outside threats wids/wips protects from external threats and potentially harmful activities originating from inside the network, providing a comprehensive wireless security solution protects wireless networks traditional ids solutions are primarily geared toward wired networks they analyze network traffic, searching for patterns or behaviors indicative of malicious activities while they are adept at detecting threats on wired networks, they might lack the specialized capabilities required to detect and mitigate threats specific to the wireless spectrum what are the different threat vectors in wireless networks? rogue access points rogue access points, or those not approved by it, can cause a security threat if permitted to connect to the network many enterprises have a policy of not allowing third party wi fi access points to connect to the corporate network if a rogue ap connects to the network, it can broadcast its own wlan to unsuspecting users this creates an entry point for non corporate devices to connect to the corporate wlan if end to end security measures are not in place this is the classic definition of a rogue ap if not detected, bad actors can safely operate outside the physical perimeter of the enterprise, connecting to the rogue’s wlan from the parking lot, finding an entry point into the enterprise lan wids and wips help to protect against rogue access points in case of nile, the wired rogue ap threat vector is less severe by a large degree as compared to tradiotional networks owing to the built in 'true' zero trust access no wired device gets on the nile network without authorization all the ports on nile switches are default enabled for either mac address by pass based authentication (mab) or 802 1x thus, nile's zero trust access posture provides a strong first line of defense against unauthorized wi fi aps getting on the network impersonation evil twins and honeypot an evil twin or honeypot ap, is a form of rogue ap that makes a malicious access point look like a legitimate one nile defines honeypot ap as the one that impersonates the ssid of a legitimate nile ap evil twin is defined as an ap that is impersonating both the ssid and the bssid used by it once users connect to the evil twin or honeypot ap, attackers can intercept any data traffic passing through this ap this is called a man in the middle attack it may result in the compromise of login credentials and other sensitive information, such as banking data if the user carries out transactions when connected to the evil twin organizations should use a wips to detect the presence of an honeypot or evil twin ap and prevent any corporate clients from connecting to them what is the difference between an evil twin/honeypot ap and a rogue ap? a rogue access point is an illegitimate access point plugged into a network to create a bypass from outside into the legitimate network it may or may not be malicious for example, an employee may connect a router that functions as a rogue ap, but without ill intent however, a lack of malicious intent does not mean that it should be connected to the network an evil twin or honeypot is also a rogue, but it is by definition malicious that’s because it is set up to impersonate a legitimate access point attackers use impersonation of ssid or ssid+bssid to lure unsuspecting victims into connecting so that they can steal information nile defines rogue ap as an unauthorized or accidentally authorized wi fi ap that is connects into a nile switch it is possible that such a wired rogue ap can additionally employ impersonation techniques as well the impersonation aps such as honeypot or evil twin may not necessarily be 'wired' to the nile switches for e g a mobile hotspot spoofing a legitimate nile ap's ssid wireless peer to peer connnections ad hoc networks or peer to peer wi fi networks typically involve a corporate issued device connecting to another non corporate network that may have been set up as a wireless network by a malicious actor connecting to one of these makes it easy for malware to infect a network since its traffic is not going through the corporate network firewall while ad hoc wi fi is a very legacy standard and almost obsolete, there might be devices out there that support other forms of direct peer to peer connections over wi fi, such as wi fi direct these standards allow end user devices to by pass the corporate policy of disallowing peer to peer traffic by default sniffers and snoopers sniffers and snoopers typically operate passively, which means that they do not send or transmit data over the network instead, they simply listen in on network traffic, intercepting and recording data packets as they are transmitted between devices on the network criminals can use commercially available software to spy on unencrypted data in transit over the air between devices and wireless access points while traffic on most websites is encrypted, this is not the case for every site mobile apps also sometimes fail to encrypt data traffic, in part because encryption imposes an overhead cost on the computing resources that support the app on the back end wids and wips do not protect against snoopers and sniffers it teams can use wpa2 or wpa3 to encrypt data in transit over the air between devices and access points dos attacks dos attacks can take several forms for example wireless interferers affecting wi fi frequencies can be used to jam certain frequencies attackers can send a flood of de authentication messages to connected devices, causing disruption to end users as they become disconnected from the network worse, this can be the first step in an evil twin/mitm attack, because when users get disconnected from a legitimate source of wireless connectivity, they may connect to the evil twin when they attempt to restore connectivity this is one example where these hacking techniques are used in combination nile's wids and wips the nile access service ensures that the overlay wireless security vector is secure nile brings the ‘nile way’ to wids by making it zero configuration, always on, and turnkey the wids functionality kicks in right at service activation, taking on the onus to expertly enable the protection and alerting against top wi fi intrusion threats nile is able to effectively detect, alert, and mitigate rogue access points from the get go the nile wids uses sophisticated correlation techniques that intelligently filter out non wired neighboring/friendly access points in the vicinity, to truly alert about real threats—such as a rogue access point that is connected to the lan the benefit of the nile's full stack wireless and wired lan service is the end to end visibility it is able to detect the port number where the rogue ap has been plugged in and block the port, thus stopping the proliferation of the intruder into the wired lan and further into the wider network furthermore, the rogue ap alert provides location information for the customer to send it personnel to physically remove such rogue aps approach to wids/wips classify successful detection starts with successful classification by learning the environment authorized aps nile aps will be authenticated automatically by nile switches, they use a trusted processing module to authenticate the nile ap to our cloud and also use macsec to authenticate the ap to the neighboring/connected switch authorized end devices following the zero trust principles within a nsb, every device connected to the nile service will be authorized and authenticated any wireless device that successfully authenticates and passes traffic through a nile ap is marked as authorized neighbor's aps in a shared environment, all the other aps in the vicinity that are not wired to the nile infrastructure are classified as neighbor's aps nile aps have a dedicated scan/monitor radio which will be able to identify the other bssids that are being broadcast within the perimeter of the rf coverage area and also ones in the vicinity such as co located tenants and/or hotspots in use nile does not use any over the air mitigation techniques such as sending spoofed deauthentication packets using threat ap's bssid detect and alert nile service will be able to detect and categorize the threats into the following rogue ap any non nile element that is connected to the service should be authorized and authenticated on to the network, so when a third party access point is connected to the nile service, assuming these devices are not authenticated via 802 1x, they will be waiting for approval navigate to the nile control center >> settings >> access management >> wired in case of nile, the wired rogue ap threat vector is less severe with nile by a large degree as compared to tradiotional networks owing the built in 'true' zero trust access no wired device gets on the nile network without authorization all the ports on nile switches are default enabled for either mac address by pass based authentication ( mab ) or 802 1x thus, nile's zero trust access posture provides a strong first line of defense against unauthorized wi fi aps getting on the network without an admin approving this request, the device will not be able to get an ip address and hence cannot pass any traffic on to the network devices can be approved through different rules such as an exact mac addresss match or oui, fingerprint in some cases customers may choose to have an all rule that allows any devices on the network if it did not match any of the specific rules although an all rule is not recommended, the option exists to offer flexibility to the customers nile's wids/wips uses the below approach to reduce friction in on boarding devices while also offering security only devices approved via ‘all’ rule in mab will be treated as less safe and go through wids mitigate if detected as rogues devices approved via specific mac address, oui or fingerprint match will be run through the wids check but only alerted for (not mitigated) this ensures that customers that have legitimate use for certain wireless access points or wireless bridges on their network can migrate smoothly to nile and continue operating these devices may exhibit rogue ap like signatures but nile will only alert for these as a security measure if a 3rd party wi fi ap connected to nile service block is approved via the all rule in mac authentication by pass it will be detected, alerted and blocked as in the example below if this device type is approved via a specific mac address match, oui or fingerprint match, nile will only alert (no port block based mitigation will be applied) navigate to nile control center >> alerts >> search for security events if the user navigates to the nile control center >> devices page, the 4th tile shows the overview of the clients detected under wids/wips clicking on the more details will take the user to rogue ap 'device details' page in the example below detailed list of events can be found if wi fi clients had connected to this rogue ap, they will show up under the misassociated device list rogue ap with nat on wired port as this is a rogue ap, most likely it might nat all the traffic out of its interface onto the nile system these are typically the wi fi routers used at home, available off the shelf they have a port marked as wan in most cases and plugs into the homes internet connection thus interface usually nat's all the traffic out this introduces some challenges in reliably detecting the presence of a wi fi rogue ap on the wired network such as office lan nile uses some techniques to inspect the egress traffic on the wan port connected into nsb when the traffic is nat'ed even though the source mac address and the ip address will be re written by the rogue ap, the nsb will see two packets with the same ip and mac address with two different ttl values and that confirms the detection of a rogue ap however, detecting the presence of a nat on the wired devices port connected into nsb, alone does not confirm the device is a wi fi ap the monitoring data collected by nile ap's monitoring radio reports all the bssids seen in the air, as well as wi fi client mac addresses that may have associated to bssids seen in the vicinity all this data is processed in the cloud to further corelate the wired and wireless mac addresses to establish a relationship between any wired mac adddresses seen on the nsb and the wi fi bssids seen in the air if a correlation is found, it can be confirmed the device observed doing nat on it's wired port is also a wi fi access point, in which cases a 'rogue ap detected' alert is generated as in the example above suspected rogue ap in some cases, it is non trivial to correlate the wired mac address of a device and wireless bssids seen in the air in many cases, the ethernet mac address may not have the same oui or fall within a certain range of any of the wireless bssids reported by nile aps nile is unable to fully qualify such wired devices as 'wi fi aps' and hence raises a 'suspected rogue ap' alert below example shows one such instance of a device that exhibited nat behavior on it's lan traffic but it's nature as a wi fi ap could not be confirmed as a safety measure, nile raises a suspected rogue ap alert for customer's it teams to be aware and inspect the devices once there are cases of laptops and workstations that may exhibit nat like behavior on their egress traffic due to the use of vpn clients, agents or use of virtual machines nile recognises that it may cause an inconvenient level of suspected rogue ap alert volume due to end devices exhibiting nat behavior hence nile provides a functionality to 'ignore' such devices from wids detection, to avoid false positive alerts the ignore functionality is quite extensive and it is covered in the sections below if the rogue ap is not nat'ing the traffic, based on the fingerprinting data and also by comparing the wired mac address with the bssid's broadcasting from the rogue ap, we will be able to detect them as rogue ap and an alert is showed on the nile control center misassociated clients these are wi fi devices that are detected as 'connected' to the rogue ap's bssid this is done based on monitoring data reported by all nile ap monitoring radios this data contains bssids seen in the vicinity as well as end device mac addresses that are seen as associated to the bssids when a end device wi fi mac is seen as associated to rogue ap bssid, it is marked as mis associated client in case of wi fi aps that act in a bridge mode, mis associated wi fi device mac address is also seen on the wired port of the nsb, which further helps in collating misassociations honeypot and evil twin ap a non nile ap broadcasting the same essid that of a authorized nile ap, is detected as ‘ honeypot’ impersonation attempt these aps are defined as non wired malicious aps that are impersonating an enterprise ap to lure clients to it as the first step to what’s to follow later these are detected based on mis match found in the monitoring data where a non nile bssid is seen advertising an ssid that belongs to the customer's active nile ap in case of malicious actor spoofing both the ssid and bssid of a legitimate nile ap, the wids detects these as evil twin impersonation attempt and alerts based on sophisiticated detection logic built around same bssid seen as active simultaneously from two sources below are examples of a honeypot alert and an evil twin alert denial of service (dos) attacks nile's wids currently detects dos attacks of two types 'broadcast deauthentication and disassociation' attempts detected as a flood from nile bssid, which seems unusually higher than normal broadcast deauthentication or disassociation packets are unusual in wi fi networks these days alerts can be found under nile control center > alerts the alert also specifies which nile aps on the floor have reported the monitoring data that assisted in detecting the dos attempt this helps customer it teams to check the area around the reporting ap in the alert second is 'unicast broadcast deauthentication and disassociation' attempts seen as a flood from nile bssid to a wi fi client mac address or vice versa, which seems unusually higher than normal these attempts are alerted for in the nile control center for customer it team's awareness and action, to check for any suspicious injectors, unidentified wi fi devices in the vicnity that may be spewing these dos floods over the air the alert also specifies which nile aps on the floor have reported the monitoring data that assisted in detecting the dos attempt this helps customer it teams to check the area around the reporting ap in the alert mitigate (rogue ap only) rogue ap after a succesful detection of a rogue ap, the nsb will take the following actions so that the ap will not be able to pass any traffic shutdown the wired port on the access switch where the rogue ap is detected change the mab rule on the nile control center from approved to denied send an alert to the customer via email/webhook if they have subscribed for it any mis associated wi fi mac addresses are also added to the mab as denied and disconnected there is no mitigation for honeypot, evil twin, dos attacks only alerts are sent to the nile control center and notifications are generated via e mail, webhook if the customer it team has setup subscription to the notification it is highly recommended to subscribe to notifications for alerts excluding trusted device from wids customers may have ‘approved’ external wi fi aps plugged into the nsb that should not trigger rogue alerts similarly, end user devices can match ‘suspected rogue’ signatures—commonly due to ttl changes from workstations running vms or vpn clients in brownfield environments, incumbent aps often remain active, leading to ssid overlap between nile and non nile aps, which is expected all these lead to rogue, suspected rogue and honeypot alerts respectively nile has introduced controls where customers can mark an oui and/or mac address of a device to be ignored from rogue and honeypot detection and alerting this provides complete control on alert volume that may be caused due to known legitimate devices that customer deems as safe excluding devices from rogue ap detection and alerting as mentioned in a previous section only devices approved via ‘all’ rule in mab will be treated as less safe and go through wids mitigate if detected as rogues devices approved via specific mac address, oui or fingerprint match will be run through the wids check but only alerted for (not mitigated) this ensures that customers that have legitimate use for certain wireless access points or wireless bridges on their network can migrate smoothly to nile and continue operating these devices may exhibit rogue ap like signatures but nile will only alert for these as a security measure there are various options to mark a mac address to be ignored from wids rogue check; either through the alert or access management options admins can use mab proactively – ideal for new on boarding, migration to nile admins can add a mac through network setup > access management > wired select the relevant options that are mandatory based on selection (for e g approved device mandates a segment selection) choose rogue ap ignore or block ignore will exclude the device matching the rule from rogue wids – no alerts, no mitigation block will perform wids mitigate action rogue ap ignore and block only supports mac address admins can use wireless access mgmt proactively – ideal for new on boarding, migration to nile understanding the bssid based rogue detection is important in order to use the ignore from wids functionality through the 'wireless access management' nile’s wids rogue ap detection can intelligently detect a wired 3rd party wi fi ap based on it’s bssid and other matching rules, even though it may not be possible to corelate this ap’s wired identity (ethernet mac) to its wireless identity (wireless mac/bssid) in such cases, admins can choose to exclude certain bssids from wids this is done through the access management page for wireless tthis is not a recommended option since bssids can be hard to find beforehand –instead use ignore/block option from the rogue ap alert that specifies it was bssid based rogue detection example of a rogue ap alert detected based on bssid is below this is an example of a rogue ap detected based on correlation of monitoring data where wids could tell there is a wi fi ap connected to a port on the nsb however, its wired ethernet mac address could not be correlated to the ap's bssid, nonetheless with a good degree of confidence it could be inferenced the rogue ap is indeed connected to the nsb over lan admins can proactively add wireless bssid mac to be ignored or blocked from wids; access management > wireless this option applies to ignoring or blocking ‘wired rogue aps’ based on their bssids/wireless macs ignore will exclude the devices matching the rule from rogue wids – no alerts, no mitigation block will perform wids mitigate action admins can take action from the suspected rogue and rogue ap alert the below example illustrates how a mac address can be ignored from wids detection and alerting the same applies to both a suspected rogue ap alert or a rogue ap alert clicking on the more details from a suspected rogue or rogue ap alert will open a drawer with option to 'ignore' or 'block' the mac address of the device shown in the alert option to ignore or block will present the user with a warning pop up, acknowleding it will add the mac address to either the ignore list from wids or block it the status of the mac address can be seen under the access management > wired tab under network setup the columns to show whether a mac address has been ignore from rogue ap detection or blocked by rogue ap detection are hidden by default on the mab access management page choose the hidden column selection and enable the rogue ap ignore and rogue ap block columns to be made visible the relevant action taken on the mac address will be displayed as below excluding devices from honeypot ap detection and alerting admins can use wireless access management proactively, under network setup > access management > wireless admins can add wireless bssid/oui to be ignored from wids honeypot check ignore will exclude the devices matching the rule from wids honeypot checks – no honeypot alerts will be generated for aps with those ouis or bssids even when found with overlapping ssid same as an activated nile ap this is ideal for brownfield customers with legacy aps still active in the vicinity of nile aps it is recommended to use oui to ignore from wids honeypot detection, to avoid adding indvidual mac addresses seen from the incumbent aps admins can take action from the honeypot alert clicking on the more details from a honeypot ap alert will open a drawer with option to 'ignore' the mac address of the device shown in the alert option to ignore will present the user with a warning pop up, acknowleding it will add the mac address to ignore list from wids honeypot detection the status of the mac address can be seen under the access management > wireless tab under network setup the honeypot ignore status column is hidden by default choose the column selector to add the honeypot ignore column to view the status of the mac addresses that have been ignored from wids honeypot ap detection