Risk should be the focus of IT and Network Engineers in 2017. It sounds boring or maybe like it’s "not my problem” but many of the threats facing organisations today could be mitigated by careful analysis and risk mitigation strategies. I often use Stuxnet as an example in what is ultimately a flawed analogy when talking to clients about risk. Stuxnet most probably did not reach it’s target via a network but it is the most memorable internally resident threat that I can think of. It’s threats of this type which are currently the most overwhelming risk to organisations' data and productivity. The threat acts from within the system and sometimes it’s successfully authenticated to the network. We need to think about networks and interconnectivity differently.
The benefits of successful risk mitigation is the reduction in downtime for users or maybe t’s zero financial loss to an organisation. Pretty compelling, right? The problem we face with computers, as we have learned over time, is that we cannot make risk equal to zero. We fight the battle with one threat and a new one appears. Software and hardware inherently holds a flaw somewhere along the way that can be compromised and there is a growing bucket of humans who are incentivised to find and take advantage of such flaws. Though we can’t win every battle it should be our duty to reduce the impact of the battles we happen to lose. Through frequent analysis of risk we can strive to better prioritise our tactics and tools for risk mitigation. Before WPA2 was available I worked my way through a Microsoft document to implement 802.1X for my wireless network. I walked through what felt like hours of steps to deploy a root CA certificate to clients, sign a certificate for a Windows IAS RADIUS and create a few rules that allowed devices to authenticate to the network. At the time it was a huge feat and a largely un-acknowledged win for security in my organisation. It was probably the best network access control of the time short of some attributes to define appropriate VLANs. When WPA2 emerged I was amazed at how simple I could convert my previous configuration to support the new standard. Back then it was all new and mostly magical, to me. Today I consult for organisations who need to enhance their network access as a basic step in risk mitigation. We make the authentication process more resilient by intelligently profiling devices as they connect to the Wi-Fi and flagging or denying devices that don’t match that profile. We enhance the authentication process so that not only does the server authenticate the client but the client mutually authenticates the server to be sure it is good. I particularly love drawing huge whiteboard diagrams of Wi-Fi based client devices and user types so we can profile who and what connects and best determine the appropriate level of access granted. For most these alone are large leaps forwards, ACLs and traffic controls are a thought for the future. In my opinion layer 2-4 traffic rules should be applied as a baseline to enhance the efficiency of Wi-Fi networks as well as reduce impact of network traversing threats. With experience and confidence in building networks with these types of controls Network Engineers will be empowered to take advantage of the next wave of risk mitigation. We are finally at the cusp of networks having a level of self awareness where real-time analysis can determine the flows of application traffic and actions can be taken to enhance or destroy the transport of the applications data. Large analyst firms are helping vendors sell new and exciting technology by building infographics showing statistics of how threats are internally born vs the “legacy” external, in-bound attacks. It’s true that we pretty much have the perimeter, Internet facing border, of our networks locked down with firewalls. It’s been that way for years. But some of that same technology that empowers our "Next Generation Firewalls” can be employed within the network because of the enhanced processing capability available today. We are seeing emerging tools which allow live analysis and risk profiling of devices and users which highlight potential internal threats as they emerge and enable action or further investigation. It’s these types of tools that will take us beyond simple authentication at the point of connection and static traffic rule-sets, to dynamic authorisation and access control. Wi-Fi networks have had deep packet inspection capability now for a few years and have allowed Network Engineers to prioritise or block network applications. This type of capability is becoming more widely available, even across the entire campus network. We will see big data collection and increasingly smart machine-learning capabilities in this space. This will allow us to make better networks that are more finely tuned to the needs of our users and critically important, will help us to reduce risk.
Comments
There are a bunch of features that are built in to network switches that generally go un-used because, simply, a switch will do it’s job right out of the box. After powering up a layer 2 or 3 switch managed switch and patching in computers and other network clients connectivity is achieved. But if that is all that is done then the wrong switch was purchased to begin with. Having a managed switch implies some configuration is likely to take place. The Layer 2 or 3 (or other) specification starts to indicate how much functionality is built in. Today, some features are are typically included across the board such as Spanning Tree or DHCP Snooping. DHCP-Snooping allows your switch to keep an eye out for DHCP responses to make sure they are coming from reliable sources, or to reduce the vectors in your network where a rogue DHCP server could operate. It does this by ensuring the DHCP responses from a server come from a trusted port and trusted IP address. It’s a simple mechanism that in simple networks could be an easy risk reduction tool - helping to reduce an attack vector. Network security should be important to us all, right? So it might not be an obvious risk to everyone. Whats the risk of multiple DHCP servers? Check out http://hakipedia.com/index.php/DHCP_Rogue_Server and for more detail go here: http://seclists.org/vuln-dev/2002/Sep/99 "Rogue DHCP servers can be stopped by means of intrusion detection systems with appropriate signatures, as well as by some multilayer switches, which can be configured to drop packets." How can you find a rogue DHCP server? Here is a quick youtube video showing how Wireshark can be used as a tool to identify a rogue DHCP server. Lets take a look at a simple configuration (performed in an HPE Aruba 3810M switch) in a network where the DHCP server is connected to switch port 10 and it’s IP address is 10.0.0.10: dhcp-snooping authorised-server 10.0.0.10 dhcp-snooping trust 10 dhcp-snooping You can see we set the server IP address 10.0.0.10 as an authorised server and trust port 10. Then dhcp-snooping enables the function. If you are using a switch or other devices as an ip helper or DHCP relay then you most likely will need to make that device an authorised DHCP server also in the DHCP Snooping configuration. Take the following network diagram as an example. The DHCP server is sitting on an entirely different network to the network devices that wish to obtain an IP address. Because DHCP is designed to work via broadcast frames on a single subnet the DHCP requests would never reach the server. This is where the switch IP Helper Address comes in. The switch will receive the DHCP requests on each of the client VLANs and forward the request on to the DHCP server. If the switch itself is not defined as an authorised server the frame returning from the DHCP server will not be forwarded on to client. Lets take a look at how DHCP-snooping should be configured for this network. dhcp-snooping authorised-server 10.0.0.10 dhcp-snooping authorised-server 10.0.10.1 dhcp-snooping authorised-server 10.0.20.1 dhcp-snooping authorised-server 10.0.30.1 dhcp-snooping trust 10 dhcp-snooping vlan 10 dhcp-snooping vlan 20 dhcp-snooping vlan 30 dhcp-snooping So here we have a configuration to authorise the DHCP server IP address and each of the interfaces within the switch for each VLAN. It’s this IP interface that will respond to DHCP requests from clients and therefore must be a trusted or authorised server. Switch port 10 is trusted as that is the uplink to the DHCP server. DHCP snooping is enabled on VLANs 10, 20 and 30 and the finally DHCP snooping is enabled. Note that if you have multiple hops to the DHCP server you should trust the uplinks (all in the case of redundant links) that will eventually lead to the DHCP server on switches further down the link chain. Configuration examples shown above are on Aruba switches (3810M and 2930F) running Aruba OS-switch version 16.03. This configuration will work across other HPE Aruba switches running similar software and is most likely the same configuration for older, non Aruba branded, HPE Pro-Curve switches. Microsoft TechNet Wiki article on How to Prevent Rogue DHCP Servers on your Network calls out the DHCP Snooping capability on network equipment https://social.technet.microsoft.com/wiki/contents/articles/25660.how-to-prevent-rogue-dhcp-servers-on-your-network.aspx * While some features may be considered common, it is always best to consult a product data-sheet or specifications documentation for each switch (or any networking products) when purchasing to ensure it does cover your requirements. While some features have been adopted as an industry standard others may be proprietary or have been implemented differently on one vendors product compared to another.
Three White House officials have reported the intentions to migrate all White House network-connected devices to a standardized White House Organizationally Unique Identifier, most commonly referred to as an OUI. "An organizationally unique identifier (OUI) is a 24-bit number that uniquely identifies a vendor, manufacturer, or other organization." It is alleged that President Donald J. Trump contacted the IEEE, which manages the computer and data inter-networking standards, to demand immediate amendments to the governing OUI rules so that all White House networked devices can have the prefix 1T:RU:MP. IEEE spokesperson, Raja Mataj, who fielded the initial request from the White House attempted to explain the difficulties in making such an amendment. Mr Mataj said he was only able to get two words in "But hexadecimal..." before the call was cut off by White House staff.
Today we're testing Aruba ClearPass Policy Manager to show that a disabled user in Active Directory will not be successfully authenticated when connecting to a WLAN using 802.1X In ClearPass it is very easy to follow and deep-dive into the information of all access request attempts using the Access Tracker. Access Tracker can be accessed from Monitoring —> Live Monitoring in the left hand navigation menu. Access Tracker has a wealth of information which can be viewed in multiple ways and is so important to a ClearPass administrator that it deserves its very own browser tab when you are making changes to and testing new configuration in ClearPass. Here in Access Tracker we can see an access event where user “matt" requests and is granted access with a resulting enforcement profile of [Allow Access Profile]. You can see the Authentication method is EAP-PEA with EAP-MSCHAPv2 which is common in a Windows Domain, the authentication source is the AD to which the ClearPass server has been joined. The Authorisation source is "WFHX AD” which is the same domain but it has been setup in such a way that ClearPass can access attributes of domain accounts (both computer and user). Here is another access event showing the same user “matt” requesting access but being denied. The domain account for “matt” was disabled. You can see the authentication source is AD but the Authorisation source is not used this time as the process does not progress beyond the rejected authentication attempt. Today my Ubertooth One arrived. I ordered this for a couple of reasons… but the main, pressing reason was I wanted to better understand Bluetooth Beacons and I need a way to packet capture in a promiscuous mode much like I can with WiFi. It seems that the Ubertooth One is the simplest and cheapest solution available - from what I found ultimately it was the only option. The Ubertooth One was created by Michael Ossmann and Dominic Spill from Great Scott Gadgets. There are a lot of instructions available… and as long as this isn’t your first time using the make command (http://linoxide.com/how-tos/linux-make-command-examples/) and you aren’t scared to type a few commands in to a terminal, command only, window then getting started isn’t too much work. If you aren’t a programmer then having some experience and patience in searching the Internet for answers then give it a go. There are some dependencies and I found this was the best place to get started: https://github.com/greatscottgadgets/ubertooth/wiki/Getting-Started but there are many other websites you will visit in the initial stages of getting your Ubertooth One going. I had to compile the firmware as the ready to go package was considered old for the host tools. https://github.com/greatscottgadgets/ubertooth/wiki/Firmware I found this out, because someone else had the issue: https://github.com/greatscottgadgets/ubertooth/issues/228 I used the latest GNU-ARM-Embedded toolchain https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads rather than the older one that was linked to elsewhere. Maybe this was good, maybe bad… It works! Here was a great piece of learning… Bluetooth packets start with a code that is based on the Lower Address Part (LAP) of a particular Bluetooth Device Address (BD_ADDR). The BD_ADDR is a 48 bit MAC address, just like the MAC address of an Ethernet device. The LAP consists of the lower 24 bits of the BD_ADDR and is the only part of the address that is transmitted with every packet. I was able to sniff these LAP’s simply with the Ubertooth One as soon as firmware was flashed and libraries and host tools installed.
Simply capturing Bluetooth in Wireshark https://github.com/greatscottgadgets/ubertooth/wiki/Capturing-BLE-in-Wireshark But the info didn’t contain what I was expecting… And then I found this… https://github.com/greatscottgadgets/libbtbb/issues/14 I need to compile some plugins for Wireshark so that it can decode the data coming from the Ubertooth correctly. It looks like there is a Mac OS bug. Next Stop Linux… More to come. Interesting reading and watching: Ubertooth Getting Started: https://github.com/greatscottgadgets/ubertooth/wiki/Getting-Started So you want to track people with Ubertooth: http://ubertooth.blogspot.com.au/2012/11/so-you-want-to-track-people-with.html I highly recommend watching this youtube video where Michael Ossmann discusses the difficulties of Bluetooth capture and more https://www.youtube.com/watch?v=KSd_1FE6z4Y Where to buy: https://www.ozhack.com/shop/bluetooth/ubertooth-one/ - For the Australian's https://greatscottgadgets.com/ubertoothone/ - for a whole range of international resellers |
WifiHaxWe build and optimise networks. Continuous learning is our secret to being good. Along the learning journey we will share things here... Archives
May 2024
Categories
All
|