Posted by: psilva | February 20, 2017

What to Expect in 2017: Mobile Device Security


mobile locksWe are mobile, our devices are mobile, the networks we connect to are mobile and the applications we access are mobile. Mobility, in all its iterations, is a huge enabler and concern for enterprises and it’ll only get worse as we start wearing our connected clothing to the office.

If the last 10 years wasn’t warning enough, 2017 will be a huge year for mobile…again. Every year, it seems, new security opportunities, challenges and questions surround the mobile landscape. And now it encompasses more than just the device that causes phantom vibration syndrome, it now involves the dizzying array of sensors, devices and automatons in our households, offices and municipalities. Mobile has infiltrated our society and our bodies along with it.

So the security stakes are high.

The more we become one with our mobile devices, the more they become targets. It holds our most precious secrets which can be very valuable. We need to use care when operating such a device since, in many ways, our lives depend on it. And with the increased automation, digitization and data gathering, there are always security concerns.

So how do we stay safe?

The consumerization of IT technologies has made us all administrators of our personal infrastructure of connected devices. Our digital self has become a life of its own. As individuals we need to stay vigilant about clicking suspicious links, updating software, changing passwords, backing up data, watching financial accounts, having AV/FW and generally locking down devices like we do the doors to our home. Even then, the smartphone enabled deadbolt can be a risk. And we haven’t even touched on mobile payment systems, IoT botnets or the untested, insecure apps on the mobile phone itself.

486744141Cybersecurity is a social issue that impacts us all and we all need to be accountable.

For enterprises, mobile devices carry an increased risk, especially personal devices connecting to an internal network. From regulatory compliance to the disgruntled employee, keeping sensitive information secret is top concern. BYOD policies and MDM solutions help as does segmenting those devices away from critical info. And the issue isn’t so much seeing restricted information, especially if your job requires it, it is more about unauthorized access if the device is compromised or lost. Many organizations have policies in place to combat this, including a total device wipe…which may also blast your personal keepsakes. The endpoint security market is maturing but won’t fill the ever-present security gaps.

From your workforce to your customers, your mobile web applications are also a target. The Anti-Phishing Working Group (APWG) reports a 250 percent jump in the number of detected phishing websites between October 2015 and March 2016. Around 230,000 unique phishing campaigns a month, many aimed at mobile devices arriving as worrisome text messages. Late 2016 saw mobile browsing overtake desktop for the first time and Google now favors mobile-friendly websites for its mobile search results. A double compatibility and SEO whammy.

And those two might not be the biggest risk to an organization since weakest link in the security ecosystem might be third-party vendors and suppliers.

On the industrial side, tractors, weather sensors, street lights, HVAC systems, your car and other critical infrastructure are now mobile devices with their own unique security implications. The Industrial Internet of Things (IIoT) focuses on industrial control systems, device to network access and all the other connective sensor capabilities. These attacks are less frequent, at least today, but the consequences can be huge – taking out industrial plants, buildings, farms, and even entire cities.

The Digital Dress Code has emerged and with 5G on the way, mobile device security takes on a whole new meaning.

ps

Related:

Posted by: psilva | February 14, 2017

Shared Authentication Domains on BIG-IP APM


How to share an APM session across multiple access profiles.

A common question for someone new to BIG-IP Access Policy Manager (APM) is how do I configure BIG-IP APM so the user only logs in once.

By default, BIG-IP APM requires authentication for each access profile.

domain value

This can easily be changed by sending the domain cookie variable is the access profile’s SSO authentication domain menu.

Let’s walk through how to configure App1 and App2 to only require authentication once.

We’ll start with App1’s Access Profile.

dv1

Once you click through to App1’s settings, in the Top menu, select SSO/Auth Domains.

dv2

For the Domain Cookie, we’ll set the value to f5demo.com since App1 and App2 use this domain and it is a FQDN. Of course, click Update.

Next, we’ll select App2’s Access Profile. Like App1, we select SSO/Auth Domains and set the Domain Cookie value to f5demo.com.

To make sure it works, we’ll launch App1 in our browser.

dv3

We’re prompted for authentication and enter our credentials and luckily, we have a successful login.

dv4

And then we’ll try to login to App2. And when we click it, we’re not prompted again for authentication information and gain access without prompts.

dv5

Granted this was a single login request for two simple applications but it can be scaled for hundreds of applications. If you‘d like to see a working demo of this, check it out here.

ps

Posted by: psilva | February 8, 2017

Lightboard Lessons: IoT on BIG-IP


As more organizations deploy IoT applications in their data centers and clouds, they’re going to need their ADC to understand the unique protocols these devices use to communicate.

In this Lightboard Lesson, I light up how IoT protocol MQTT (Message Queuing Telemetry Transport) works on BIG-IP v13. iRules allow you to do Topic based load balancing along with sensor authentication. And if you missed it, here is the #LBL on What is MQTT?

ps

Related:

Posted by: psilva | February 7, 2017

Security Trends in 2016: Securing the Internet of Things


mirai-trojanWhenever you connect anything to the internet, there is risk involved. Just ask the millions of IoT zombies infected with Mirai. Sure, there have been various stories over the years about hacking thermostats, refrigerators, cameras, pacemakers, insulin pumps and other medical devices along with cars, homes and hotel rooms…but Mirai took it to a new level.

And it’s not the only IoT botnet out there nor are these nasty botnets going away anytime soon. There’s a gold mine of unprotected devices out there waiting to either have their/your info stolen or be used to flood another website with traffic.

This is bound to compound in the years to come.

A recent Ponemon Institute report noted that an incredible 80% of IoT applications are not tested for vulnerabilities. Let’s try that again – only 20% of the IoT applications that we use daily are tested for vulnerabilities. There’s probably no indication or guarantee that the one you are using now has been tested.

R025_Fig1_1Clearly a trend we saw in 2016, and seems to continue into 2017, is that people are focusing too much on the ‘things’ themselves and the coolness factor rather than the fact that anytime you connect something to the internet, you are potentially exposing yourself to thieves. There has been such a rush to get products to market and make some money off a new trend yet these same companies ignore or simply do not understand the potential security threats. This somewhat mimics the early days of internet connectivity when insecure PCs dialed up and were instantly inundated with worms, viruses and email spam. AV/FW software soon came along and intended to reduce those threats.

Today it’s a bit different but the cycle continues.

Back then you’d probably notice that your computer was acting funky, slowing down or malfunctioning since we interacted with it daily. Today, we typically do not spend every waking hour working with our IoT devices. They’re meant to function independently to grab data, make adjustments and alert us on a mobile app with limited human interaction. That’s the ‘smart’ part everyone talks about. But these botnets are smart themselves. With that, you may never know that your DVR is infected and allowing someone across the globe (or waiting at the nearest street corner) watch your every move.

Typical precautions we usually hear are actions like changing default passwords, not connecting it directly to the internet and updating the firmware to reduce the exposure. Software developers, too, need to plan and build in security from the onset rather than an afterthought. The security vs. usability conundrum that plagues many web applications extends to IoT applications also. But you wouldn’t, or I should say, shouldn’t deploy a financial application without properly testing it for vulnerabilities. There the risk is financial loss but with IoT and particularly medical/health devices the result can be deadly.

Mirai was just the beginning of the next wave of vulnerability exploitation. More chaos to come.

ps

Related:

Posted by: psilva | February 2, 2017

What is DNS?


devcentral_basics_article_banner

What is the Domain Name System (DNS)?

Imagine how difficult it would be to use the Internet if you had to remember dozens of number combinations to do anything. The Domain Name System (DNS) was created in 1983 to enable humans to easily identify all the computers, services, and resources connected to the Internet by name—instead of by Internet Protocol (IP) address, an increasingly difficult-to-memorize string of information. Think of all the website domain names you know off the top of your head and how hard it would be to memorize specific IP addresses for all those domain names. Think of DNS as the Internet’s phone book. A DNS server translates the domain names you type into a browser, like www.f5.com, into an IP address (104.219.105.148), which allows your device to find the resource you’re looking for on the Internet.

DNS is a hierarchical distributed naming system for computers, services, or other resources connected to the Internet. It associates various information with domain names that are assigned to each of the participating DNS entries.

How DNS Works

The user types the address of the site (www.f5.com as an example) into the web browser. The browser has no clue where www.f5.com is, so it sends a request to the Local DNS Server (LDNS) to ask if it has a record for www.f5.com. If the LDNS does not have a record for that particular site, it begins a recursive search of the Internet domains to find out who owns www.f5.com.

First, the LDNS contacts one of the Root DNS Servers, and the Root Server responds by telling the LDNS to contact the .com DNS Server. The LDNS then asks the .com DNS Server if it has a record for www.f5.com, and the .com DNS Server determines the owner of www.f5.com and returns a Name Server (NS) record for f5.com. Check out the diagram below:

dns1

Next, the LDNS queries the f5.com DNS Server NS record. The f5.com DNS Server looks up the name: www.f5.com. If it finds the name, it returns an Address (A) record to the LDNS. The A record contains the name, IP address, and Time to Live (TTL). The TTL (measured in seconds) tells the LDNS how long to maintain the A record before it asks the f5.com DNS Server again.

When the LDNS receives the A record, it caches the IP address for the time specified in the TTL. Now that the LDNS had the A record for www.f5.com, it can answer future requests from its own cache rather than completing the entire recursive search again. LDNS returns the IP address of www.f5.com to the host computer, and the local browser caches the IP address on the computer for the time specified in the TTL. After all, if it can hold on to the info locally, it won’t need to keep asking the LDNS.

dns2

The browser then uses the IP address to open a connection to www.f5.com:80 and sends a GET /… and the web server returns the web page response.

dns3

DNS can get a lot more complicated than what this simple example shows, but this gives you an idea of how it works.

DNS Importance

As arguably the primary technology enabling the Internet, DNS is also one of the most important components in networking infrastructure. In addition to delivering content and applications, DNS also manages a distributed and redundant architecture to ensure high availability and quality user response time—so it is critical to have an available, intelligent, secure, and scalable DNS infrastructure. If DNS fails, most web applications will fail to function properly. And DNS is a prime target for attack.

The importance of a strong DNS foundation cannot be overstated. Without one, your customers may not be able to access your content and applications when they want to—and if they can’t get what they want from you, they’ll likely turn elsewhere.

Growing Pains

DNS is growing especially with mobile apps and IoT devices requiring name resolution.  Add to that, organizations are experiencing rapid growth in terms of applications as well as the volume of traffic accessing those applications.

In the last five years, the volume of DNS queries on for .com and .net addresses has more than doubled. More than 10 million domain names were added to the Internet in 2016 and future growth is expected to occur at an even faster pace as more cloud, mobile and IoT implementations are deployed.

Security Issues

If DNS is the backbone of the Internet—answering all the queries and resolving all the numbers so you can find your favorite sites—it is also one of the most vulnerable points in your network. Due to the crucial role it plays, DNS is a high-value security target. DNS DDoS attacks can flood your DNS servers to the point of failure or hijack the request and redirect requests to a malicious server. To prevent this, a distributed high-performing, secure DNS architecture and DNS offload capabilities must be integrated into the network.

Generally, DNS servers and DNS cloud services can handle varying amounts of requests per second with the costs increasing as the queries-per-second increase.

To address DNS surges and DNS DDoS attacks, companies add more DNS servers, which are not really needed during normal business operations. This costly solution also often requires manual intervention for changes. In addition, traditional DNS servers require frequent maintenance and patching, primarily for new vulnerabilities.

The Traditional Solution

When looking for DNS solutions, many organizations select BIND (Berkeley Internet Naming Daemon), the Internet’s original DNS resolver. Installed on approximately 80 percent of the world’s DNS servers, BIND is an open-source project maintained by Internet Systems Consortium (ISC).

Despite its popularity, BIND requires significant maintenance multiple times a year primarily due to vulnerabilities, patches, and upgrades. It can be downloaded freely, but needs servers (an additional cost, including support contracts) and an operating system. In addition, BIND typically scales to only 50,000 responses per second (RPS), making it vulnerable to both legitimate and malicious DNS surges.

Next Step

If you’re ready to learn more or dig deeper into DNS, check out these more advanced articles


kai wilke1Kai Wilke is a Principal Consultant for IT Security at itacs GmbH – a German consulting company located in Berlin City specializing in Microsoft security solutions, SharePoint deployments, and customizations as well as classical IT Consulting. He is also a 2017 DevCentral MVP and DevCentral’s Featured Member for February!

For almost 20 years in IT, he’s constantly explored the evens and odds of various technologies, including different operating systems, SSO and authentication services, RBAC models, PKI and cryptography components, HTTP-based services, proxy servers, firewalls, and core networking components. His focus in these areas has always been security related and included the design, implementation and review of secure and high availability/high performance datacenters.

DevCentral got a chance to talk with Kai about his work, life and mastery of iRules.

DevCentral: You’ve been a very active contributor to the DevCentral community and wondered what keeps you involved?

Kai: Working with online communities has always been an important thing for me and it began long time ago within the good old Usenet and the predecessor of the Darknet. Before joining the F5 community, I was also once an honored member of the Microsoft Online Community and was five times awarded as a Microsoft MVP for Enterprise Security and Microsoft-related firewall/proxy server technologies.

My opinion is that if you want to become an expert for a certain technology or product, you should not just learn THE-ONE straight-forward method fetched from manuals, guides or even exams. Instead, you have to dive deeply into all of those edge scenarios and learn all the uncountable ways to mess the things up. And dealing with questions and problems of other peers is probably the best catalyst to gain that kind of experience.

Besides of that, the quality of the DevCentral content and the knowledge of other community members are absolutely astonishing. It makes simply a lot of fun for me to work within the DevCentral community and to learn every day a little bit more…

DC: Tell us a little about the areas of BIG-IP expertise you have.

KW: Over the years, I successfully implemented BIG-IP LTM, APM, ASM, and DNS Service deployments for our customers. Technologically, I internalized TMOS and its architecture very well and I pretty much learned how to write simple but also somewhat complex iRules to control the delivery of arbitrary data on their way from A to B in any possible fashion.

DC: You are a Principal Consultant for IT Security at itacs GmbH – a German consulting company. Can you describe your typical workday?

KW: Because of my history with Microsoft related infrastructures, my current workload is pretty versatile.

itacs logoMany of my current projects are still settled in the Microsoft / Windows system environment and are covering the design and review of security related areas. Right now, I’m working with several DAX companies and also LaaS, PaaS and SaaS service providers to analyze their Active Directory and System Management infrastructures and to design and implement a very unique, fundamental and comprehensive security concept to counter those dreaded PtH (Pass-the-Hash) and APT (Advance Persistent Threat) attacks we are facing these days.

Over the last years, my F5 customer base has periodically grown so I would say my work is a 50:50 mix right now. I do F5 workshops, designs, implementations, second and third level support as well as configuration reviews and optimization of existing environments. I work with some big web 2.0 customers that have the demand to pretty much exhaust all the capabilities of an F5. This challenges me as a network architect and as an ADC developer.

I realize every day that working with F5 products makes so much more fun than any Microsoft product I have ever dealt with. So in the future, I will even more put my focus on F5!

DC: Describe one of your biggest BIG-IP challenges and how DevCentral helped in that situation.

KW: In my opinion, the F5 products themselves are not that challenging – but sometimes the underlying technologies and the detailed project requirements are. But as long as those requirements can be drawn and explained on a sheet of paper, I am somewhat confident that the BIG-IP platform is able to support the requirements – thanks to the F5 developers who have created a platform which is not purely scenario driven but rather supports a comprehensive list of RFC standards which can be combined as needed.

For an example, one of my largest customers operates an affiliate resource tracking system with three billion web requests per day with a pretty much aggressive session setup rate during peak hours. I have designed and implemented their BIG-IP LTM platform to offload SSL-encryption and the TCP-connection handling to various backend systems using well selected and performance optimized settings.

Other scenarios require slightly more complex content switching, the selective use of pre-authentication and/or combination with IDS/IPS systems. To support those requirements, I developed a very granular and scalable iRule administration framework which is able to simplify the configuration by using rather easy-to-use iRule configuration files (operated by non TCL developers) which will then trigger the much more complex iRule code (written and tested by TCL developers) as needed. The latest version of my iRule administration framework (which is currently under testing/development) will be able to support a couple thousand websites on a single Virtual Server, where each websites can trigger handcrafted TCL code blocks as needed, but without adding linear or even exponential overhead to the system as the regular iRule approaches would do. The core and the configuration files of the latest version are heavily based on TCL procedures to create a very flexible code base and also conditional control structures, but completely without calling any TCL procedures during runtime to boost the performance dramatically. Sounds interesting? Then stay tuned, I am sure I will publish this framework to the CodeShare once it’s stable enough… 😉

DC: Lastly, if you weren’t an IT admin – what would be your dream job? Or better, when you were a kid – what did you want to be when you grew up?

KW: I was typing my first assembler code out of a C64 magazine at the age of 10, so I really wanted to be a developer and/or IT admin since then. But besides of my current job, I can also imagine being a racecar driver. I really have petrol in my blood and pretty much enjoy driving on the German Autobahn. As an alternative, I could also imagine being a cook. I really love cooking and enjoy awesome food!

DC: Thanks Kai! Just don’t fire up that sterno while shifting gears!! Check out all of Kai’s DevCentral contributions and check out their blog websites: ops365.de, flow365.de and brandmysharepoint.de.

Posted by: psilva | January 26, 2017

What is an Application Delivery Controller – Part II


devcentral_basics_article_banner

Application Delivery Basics

One of the unfortunate effects of the continued evolution of the load balancer into today’s application delivery controller (ADC) is that it is often too easy to forget the basic problem for which load balancers were originally created—producing highly available, scalable, and predictable application services. We get too lost in the realm of intelligent application routing, virtualized application services, and shared infrastructure deployments to remember that none of these things are possible without a firm basis in basic load balancing technology. So how important is load balancing, and how do its effects lead to streamlined application delivery?

Let’s examine the basic application delivery transaction. The ADC will typically sit in-line between the client and the hosts that provide the services the client wants to use. As with most things in application delivery, this is not a rule, but more of a best practice in a typical deployment. Let’s also assume that the ADC is already configured with a virtual server that points to a cluster consisting of two service points. In this deployment scenario, it is common for the hosts to have a return route that points back to the load balancer so that return traffic will be processed through it on its way back to the client.

The basic application delivery transaction is as follows:

  1. The client attempts to connect with the service on the ADC.
  2. The ADC accepts the connection, and after deciding which host should receive the connection, changes the destination IP (and possibly port) to match the service of the selected host (note that the source IP of the client is not touched).
  3. The host accepts the connection and responds back to the original source, the client, via its default route, the load balancer.
  4. The ADC intercepts the return packet from the host and now changes the source IP (and possible port) to match the virtual server IP and port, and forwards the packet back to the client.
  5. The client receives the return packet, believing that it came from the virtual server or host, and continues the process.

how lb works

Figure 1. A basic load balancing transaction.

This very simple example is relatively straightforward, but there are a couple of key elements to take note of. First, as far as the client knows, it sends packets to the virtual server and the virtual server responds—simple. Second, the NAT takes place. This is where the ADC replaces the destination IP sent by the client (of the virtual server) with the destination IP of the host to which it has chosen to load balance the request. Step three is the second half of this process (the part that makes the NAT “bi-directional”). The source IP of the return packet from the host will be the IP of the host; if this address were not changed and the packet was simply forwarded to the client, the client would be receiving a packet from someone it didn’t request one from, and would simply drop it. Instead, the ADC, remembering the connection, rewrites the packet so that the source IP is that of the virtual server, thus solving this problem.

The Application Delivery Decision

So, how does the ADC decide which host to send the connection to? And what happens if the selected host isn’t working?

Let’s discuss the second question first. What happens if the selected host isn’t working? The simple answer is that it doesn’t respond to the client request and the connection attempt eventually times out and fails. This is obviously not a preferred circumstance, as it doesn’t ensure high availability. That’s why most ADC technology includes some level of health monitoring that determines whether a host is actually available before attempting to send connections to it.

There are multiple levels of health monitoring, each with increasing granularity and focus. A basic monitor would simply PING the host itself. If the host does not respond to PING, it is a good assumption that any services defined on the host are probably down and should be removed from the cluster of available services. Unfortunately, even if the host responds to PING, it doesn’t necessarily mean the service itself is working. Therefore most devices can do “service PINGs” of some kind, ranging from simple TCP connections all the way to interacting with the application via a scripted or intelligent interaction. These higher-level health monitors not only provide greater confidence in the availability of the actual services (as opposed to the host), but they also allow the load balancer to differentiate between multiple services on a single host. The ADC understands that while one service might be unavailable, other services on the same host might be working just fine and should still be considered as valid destinations for user traffic.

This brings us back to the first question: How does the ADC decide which host to send a connection request to? Each virtual server has a specific dedicated cluster of services (listing the hosts that offer that service) which makes up the list of possibilities. Additionally, the health monitoring modifies that list to make a list of “currently available” hosts that provide the indicated service. It is this modified list from which the ADC chooses the host that will receive a new connection. Deciding the exact host depends on the ADC algorithm associated with that particular cluster. The most common is simple round-robin where the ADC simply goes down the list starting at the top and allocates each new connection to the next host; when it reaches the bottom of the list, it simply starts again at the top. While this is simple and very predictable, it assumes that all connections will have a similar load and duration on the back-end host, which is not always true. More advanced algorithms use things like current-connection counts, host utilization, and even real-world response times for existing traffic to the host in order to pick the most appropriate host from the available cluster services.

Sufficiently advanced application delivery systems will also be able to synthesize health monitoring information with load balancing algorithms to include an understanding of service dependency. This is the case when a single host has multiple services, all of which are necessary to complete the user’s request. A common example would be in e-commerce situations where a single host will provide both standard HTTP services (port 80) as well as HTTPS (SSL/TLS at port 443) and any other potential service ports that need to be allowed. In many of these circumstances, you don’t want a user going to a host that has one service operational, but not the other. In other words, if the HTTPS services should fail on a host, you also want that host’s HTTP service to be taken out of the cluster list of available services. This functionality is increasingly important as HTTP-like services become more differentiated with this things like XML and scripting.

To Load Balance or Not to Load Balance?

Load balancing in regards to picking an available service when a client initiates a transaction request is only half of the solution. Once the connection is established, the ADC must keep track of whether the following traffic from that user should be load balanced. There are generally two specific issues with handling follow-on traffic once it has been load balanced: connection maintenance and persistence.

Connection maintenance

If the user is trying to utilize a long-lived TCP connection (telnet, FTP, and more) that doesn’t immediately close, the ADC must ensure that multiple data packets carried across that connection do not get load balanced to other available service hosts. This is connection maintenance and requires two key capabilities: 1) the ability to keep track of open connections and the host service they belong to; and 2) the ability to continue to monitor that connection so the connection table can be updated when the connection closes. This is rather standard fare for most ADCs.

Persistence

Increasingly more common, however, is when the client uses multiple short-lived TCP connections (for example, HTTP) to accomplish a single task. In some cases, like standard web browsing, it doesn’t matter and each new request can go to any of the back-end service hosts; however, there are many more instances (XML, JavaScript, e-commerce “shopping cart,” HTTPS, and so on) where it is extremely important that multiple connections from the same user go to the same back-end service host and not be load balanced. This concept is called persistence, or server affinity. There are multiple ways to address this depending on the protocol and the desired results. For example, in modern HTTP transactions, the server can specify a “keep-alive” connection, which turns those multiple short-lived connections into a single long-lived connection that can be handled just like the other long-lived connections. However, this provides little relief. Even worse, as the use of web and mobile services increases, keeping all of these connections open longer than necessary would strain the resources of the entire system. In these cases, most ADCs provide other mechanisms for creating artificial server affinity.

One of the most basic forms of persistence is source-address affinity. Source address affinity persistence directs session requests to the same server based solely on the source IP address of a packet. This involves simply recording the source IP address of incoming requests and the service host they were load balanced to, and making all future transaction go to the same host. This is also an easy way to deal with application dependency as it can be applied across all virtual servers and all services. In practice however, the wide-spread use of proxy servers on the Internet and internally in enterprise networks renders this form of persistence almost useless; in theory it works, but proxy-servers inherently hide many users behind a single IP address resulting in none of those users being load balanced after the first user’s request—essentially nullifying the ADC capability. Today, the intelligence of ADCs allows organizations to actually open up the data packets and create persistence tables for virtually anything within it. This enables them to use much more unique and identifiable information, such as user name, to maintain persistence. However, organizations one must take care to ensure that this identifiable client information will be present in every request made, as any packets without it will not be persisted and will be load balanced again, most likely breaking the application.

Final Thoughts

It is important to understand that basic load balancing technology, while still in use, is now only considered a feature of Application Delivery Controllers. ADCs evolved from the first load balancers through the service virtualization process and today with software only virtual editions. They can not only improve availability, but also affect the security and performance of the application services being requested.

Today, most organizations realize that simply being able to reach an application doesn’t make it usable; and unusable applications mean wasted time and money for the enterprise deploying them. ADCs enable organizations to consolidate network-based services like SSL/TLS offload, caching, compression, rate-shaping, intrusion detection, application firewalls, and even remote access into a single strategic point that can be shared and reused across all application services and all hosts to create a virtualized Application Delivery Network. Basic load balancing is the foundation without which none of the enhanced functionality of today’s ADCs would be possible.

And if you missed What is an ADC Part 1, you can find it here.

ps

Next Steps

Now that you’ve gotten this far, would you like to dig deeper or learn more about how application delivery works? Cool, then check out these resources:

Posted by: psilva | January 24, 2017

What is an Application Delivery Controller – Part 1


devcentral_basics_article_banner

A Little History

Application Delivery got its start in the form of network-based load balancing hardware. It is the essential foundation on which Application Delivery Controllers (ADCs) operate. The second iteration of purpose-built load balancing (following application-based proprietary systems) materialized in the form of network-based appliances. These are the true founding fathers of today’s ADCs. Because these devices were application-neutral and resided outside of the application servers themselves, they could load balance using straightforward network techniques. In essence, these devices would present a “virtual server” address to the outside world, and when users attempted to connect, they would forward the connection to the most appropriate real server doing bi-directional network address translation (NAT).

network lb (1)

Figure 1: Network-based load balancing appliances.

With the advent of virtualization and cloud computing, the third iteration of ADCs arrived as software delivered virtual editions intended to run on hypervisors. Virtual editions of application delivery services have the same breadth of features as those that run on purpose-built hardware and remove much of the complexity from moving application services between virtual, cloud, and hybrid environments. They allow organizations to quickly and easily spin-up application services in private or public cloud environments.

Basic Application Delivery Terminology

It would certainly help if everyone used the same lexicon; unfortunately, every vendor of load balancing devices (and, in turn, ADCs) seems to use different terminology. With a little explanation, however, the confusion surrounding this issue can easily be alleviated.

Node, Host, Member, and Server

Most ADCs have the concept of a node, host, member, or server; some have all four, but they mean different things. There are two basic concepts that they all try to express. One concept—usually called a node or server—is the idea of the physical or virtual server itself that will receive traffic from the ADC. This is synonymous with the IP address of the physical server and, in the absence of a ADC, would be the IP address that the server name (for example, www.example.com) would resolve to. We will refer to this concept as the host.

The second concept is a member (sometimes, unfortunately, also called a node by some manufacturers). A member is usually a little more defined than a server/node in that it includes the TCP port of the actual application that will be receiving traffic. For instance, a server named www.example.com may resolve to an address of 172.16.1.10, which represents the server/node, and may have an application (a web server) running on TCP port 80, making the member address 172.16.1.10:80. Simply put, the member includes the definition of the application port as well as the IP address of the physical server.  We will refer to this as the service.

Why all the complication? Because the distinction between a physical server and the application services running on it allows the ADC to individually interact with the applications rather than the underlying hardware or hypervisor. A host (172.16.1.10) may have more than one service available (HTTP, FTP, DNS, and so on). By defining each application uniquely (172.16.1.10:80, 172.16.1.10:21, and 172.16.1.10:53), the ADC can apply unique load balancing and health monitoring based on the services instead of the host. However, there are still times when being able to interact with the host (like low-level health monitoring or when taking a server offline for maintenance) is extremely convenient.

Most load balancing-based technology uses some concept to represent the host, or physical server, and another to represent the services available on it— in this case, simply host and services.

Pool, Cluster, and Farm

Load balancing allows organizations to distribute inbound application traffic across multiple back-end destinations, including cloud deployments. It is therefore a necessity to have the concept of a collection of back-end destinations. Clusters, as we will refer to them (also known as pools or farms) are collections of similar services available on any number of hosts. For instance, all services that offer the company web page would be collected into a cluster called “company web page” and all services that offer e-commerce services would be collected into a cluster called “e-commerce.”

The key element here is that all systems have a collective object that refers to “all similar services” and makes it easier to work with them as a single unit. This collective object—a cluster—is almost always made up of services, not hosts.

Virtual Server

Although not always the case, today the term virtual server means a server hosting virtual machines. It is important to note that like the definition of services, virtual server usually includes the application port was well as the IP address. The term “virtual service” would be more in keeping with the IP:Port convention; but because most vendors, ADC and Cloud alike use virtual server, this article uses virtual server as well.

Putting It All Together

Putting all of these concepts together makes up the basic steps in load balancing. The ADC presents virtual servers to the outside world. Each virtual server points to a cluster of services that reside on one or more physical hosts.

adc parts (1)

Figure 2: Application Delivery comprises four basic concepts—virtual servers, clusters, services, and hosts.

While the diagram above may not be representative of a real-world deployment, it does provide the elemental structure for continuing a discussion about application delivery basics.

Next Steps

Read What is Load Balancing? if you haven’t already and check out ADC Part II coming January 26!

ps

Posted by: psilva | January 23, 2017

What is Load Balancing?


devcentral_basics_article_banner

The entire intent of load balancing is to create a system that virtualizes the “service” from the physical servers that actually run that service. A more basic definition is to balance the load across a bunch of physical servers and make those servers look like one great big server to the outside world. There are many reasons to do this, but the primary drivers can be summarized as “scalability,” “high availability,” and “predictability.”

Scalability is the capability of dynamically, or easily, adapting to increased load without impacting existing performance. Service virtualization presented an interesting opportunity for scalability; if the service, or the point of user contact, was separated from the actual servers, scaling of the application would simply mean adding more servers or cloud resources which would not be visible to the end user.

High Availability (HA) is the capability of a site to remain available and accessible even during the failure of one or more systems. Service virtualization also presented an opportunity for HA; if the point of user contact was separated from the actual servers, the failure of an individual server would not render the entire application unavailable. Predictability is a little less clear as it represents pieces of HA as well as some lessons learned along the way. However, predictability can best be described as the capability of having confidence and control in how the services are being delivered and when they are being delivered in regards to availability, performance, and so on.

A Little Background

Back in the early days of the commercial Internet, many would-be dot-com millionaires discovered a serious problem in their plans. Mainframes didn’t have web server software (not until the AS/400e, anyway) and even if they did, they couldn’t afford them on their start-up budgets. What they could afford was standard, off-the-shelf server hardware from one of the ubiquitous PC manufacturers. The problem for most of them? There was no way that a single PC-based server was ever going to handle the amount of traffic their idea would generate and if it went down, they were offline and out of business. Fortunately, some of those folks actually had plans to make their millions by solving that particular problem; thus was born the load balancing market.

In the Beginning, There Was DNS

Before there were any commercially available, purpose-built load balancing devices, there were many attempts to utilize existing technology to achieve the goals of scalability and HA. The most prevalent, and still used, technology was DNS round-robin. Domain name system (DNS) is the service that translates human-readable names (www.example.com) into machine recognized IP addresses. DNS also provided a way in which each request for name resolution could be answered with multiple IP addresses in different order.

dns lb1Figure 1: Basic DNS response for redundancy

The first time a user requested resolution for www.example.com, the DNS server would hand back multiple addresses (one for each server that hosted the application) in order, say 1, 2, and 3. The next time, the DNS server would give back the same addresses, but this time as 2, 3, and 1. This solution was simple and provided the basic characteristics of what customer were looking for by distributing users sequentially across multiple physical machines using the name as the virtualization point.

From a scalability standpoint, this solution worked remarkable well; probably the reason why derivatives of this method are still in use today particularly in regards to global load balancing or the distribution of load to different service points around the world. As the service needed to grow, all the business owner needed to do was add a new server, include its IP address in the DNS records, and voila, increased capacity. One note, however, is that DNS responses do have a maximum length that is typically allowed, so there is a potential to outgrow or scale beyond this solution.

This solution did little to improve HA. First off, DNS has no capability of knowing if the servers listed are actually working or not, so if a server became unavailable and a user tried to access it before the DNS administrators knew of the failure and removed it from the DNS list, they might get an IP address for a server that didn’t work.

Proprietary Load Balancing in Software

One of the first purpose-built solutions to the load balancing problem was the development of load balancing capabilities built directly into the application software or the operating system (OS) of the application server. While there were as many different implementations as there were companies who developed them, most of the solutions revolved around basic network trickery. For example, one such solution had all of the servers in a cluster listen to a “cluster IP” in addition to their own physical IP address.

cluster lb1

Figure 2: Proprietary cluster IP load balancing

When the user attempted to connect to the service, they connected to the cluster IP instead of to the physical IP of the server. Whichever server in the cluster responded to the connection request first would redirect them to a physical IP address (either their own or another system in the cluster) and the service session would start. One of the key benefits of this solution is that the application developers could use a variety of information to determine which physical IP address the client should connect to. For instance, they could have each server in the cluster maintain a count of how many sessions each clustered member was already servicing and have any new requests directed to the least utilized server.

Initially, the scalability of this solution was readily apparent. All you had to do was build a new server, add it to the cluster, and you grew the capacity of your application. Over time, however, the scalability of application-based load balancing came into question. Because the clustered members needed to stay in constant contact with each other concerning who the next connection should go to, the network traffic between the clustered members increased exponentially with each new server added to the cluster. The scalability was great as long as you didn’t need to exceed a small number of servers.

HA was dramatically increased with these solutions. However, since each iteration of intelligence-enabling HA characteristics had a corresponding server and network utilization impact, this also limited scalability. The other negative HA impact was in the realm of reliability.

Network-Based Load balancing Hardware

The second iteration of purpose-built load balancing came about as network-based appliances. These are the true founding fathers of today’s Application Delivery Controllers. Because these boxes were application-neutral and resided outside of the application servers themselves, they could achieve their load balancing using much more straight-forward network techniques. In essence, these devices would present a virtual server address to the outside world and when users attempted to connect, it would forward the connection on the most appropriate real server doing bi-directional network address translation (NAT).

hw lb (1)

Figure 3: Load balancing with network-based hardware

The load balancer could control exactly which server received which connection and employed “health monitors” of increasing complexity to ensure that the application server (a real, physical server) was responding as needed; if not, it would automatically stop sending traffic to that server until it produced the desired response (indicating that the server was functioning properly). Although the health monitors were rarely as comprehensive as the ones built by the application developers themselves, the network-based hardware approach could provide at least basic load balancing services to nearly every application in a uniform, consistent manner—finally creating a truly virtualized service entry point unique to the application servers serving it.

Scalability with this solution was only limited by the throughput of the load balancing equipment and the networks attached to it. It was not uncommon for organization replacing software-based load balancing with a hardware-based solution to see a dramatic drop in the utilization of their servers. HA was also dramatically reinforced with a hardware-based solution. Predictability was a core component added by the network-based load balancing hardware since it was much easier to predict where a new connection would be directed and much easier to manipulate.

The advent of the network-based load balancer ushered in a whole new era in the architecture of applications. HA discussions that once revolved around “uptime” quickly became arguments about the meaning of “available” (if a user has to wait 30 seconds for a response, is it available? What about one minute?).

This is the basis from which Application Delivery Controllers (ADCs) originated.

The ADC

Simply put, ADCs are what all good load balancers grew up to be. While most ADC conversations rarely mention load balancing, without the capabilities of the network-based hardware load balancer, they would be unable to affect application delivery at all. Today, we talk about security, availability, and performance, but the underlying load balancing technology is critical to the execution of all.

Next Steps

Ready to plunge into the next level of Load Balancing? Take a peek at these resources:

ps

Posted by: psilva | January 17, 2017

Deploy BIG-IP VE in AWS


aws logoCloud is all the rage these days as it has matured into a bona fide, viable option to deploy your applications. While attractive, you may also want to apply, mimic or sync your traditional data center policies like high availability, scalability and predictability in the cloud.

Here we’ll walk through how to create a simple single NIC (sometimes called “one ARM”) instance of BIG-IP VE in the Amazon Web Services console.

Open the AWS management console and click VPC (Virtual Private Cloud) to dive right into the VPC wizard and create a simple, single public subnet VPC.

aws1

Give it a name, accept the other defaults and click Create VPC. When it creates a VPC, it also creates a security group for the VPC. There we’ll want to check some of the rules associated with the security group.

vpc security

You may also want to update the Name tag field so you can more easily find your group going forward.

vpc sec rules

The source can be the security group itself or you can replace with a specific IP range. While not the safest, here we’re allowing all traffic. You can also edit the outbound rules if needed.

Next, for our application server, we’ll want to create an EC2 instance of a Microsoft Windows machine with a webpage on it in the VPC. The location of your application server is up to you. For this article, you can see we’ve created an application server with a private IP address along with a corresponding public IP address. You don’t need the public address unless you need to connect directly to the app server.

aws2 ec2

Next we’ll want to deploy an instance of BIG-IP in the VPC. We’ll search the Marketplace for BIG-IP hourly but you can also use your current BIG-IP license in a Bring Your Own License scenario. There are various throughput limits and BIG-IP module bundles so choose what’s appropriate for your situation. (See this doc for more info on recommended instances)

We’ll choose our region and click continue and then Launch.

aws3 bigip

We’ll then want to select an instance type and when we get to the Instance Details screen, we’ll choose the VPC and subnet we created earlier. You can make more adjustments here or simply accept the auto-assign defaults.

aws4 steps23

We’ll move through the Storage step and hit the Add Tags spot and give it a name value, like BIG-IP VE1. Often it is just a simple name so you can find it in the list of instances.

aws s5 tags

Next we select the existing security group we created or we can create a new one. Since the one we created was wide open, you could create one that allows only port 22 (for SSH), port 443 (for web application/virtual server traffic), and 8443 (for management/Config utility access).

aws5 sectypes

Once that’s done we’ll click launch and select our key pair. You’ll use the key pair when you use SSH to connect to BIG-IP VE.

aws6 key launch

We get the status page as it launches. The one thing to remember is to allocate an elastic public IP so the BIG-IP instance can hit the license server for verification. You can also use that public IP to connect to the config utility and as the Virtual server address. Once the BIG-IP instance is up and running, you can’t access it until you’ve connected and set a strong admin password. You can do this with PuTTy and the key (Connection > SSH >Auth).

aws7 putty

Once we’ve locked it down with a strong password, we’ll use the public IP and take a look at the Config utility which allows us to manage our BIG-IP. Using the new password, now we’re able to start the BIG-IP setup wizard like you would any other BIG-IP. That public IP will be the target to serve traffic to the application through BIG-IP.

aws8 bigipsetup

From here, you can also update management ports, provision modules, and of course, create the virtual server(s) and pools for your application.

Go back to the AWS console, get the private address of the webserver and that becomes the resource address for your pool.

aws9 poolip

Same thing for the virtual server. Go to AWS, grab the BIG-IP private address (as opposed to the webserver above) and that is what you enter for the virtual server.

aws91 vsip

aws vs live

Finish the other resource settings, including the appropriate pool and the virtual server is live and visitors can now enjoy the application. We can add whatever services and profiles we need for a fast, available and secure application.

ps

Related:

Older Posts »

Categories