Implementing Lightweight East-West Firewalls with F5
In 2005, perpetual diva Miss Piggy portrayed all four of the directional witches (North, South, East and West) in Jim Henson’s Muppet’s Wizard of Oz. Despite a vigorous and, occasionally violent, performance, she was snubbed at the Academy Awards, ultimately losing out to Reese Witherspoon (Walk the Line). Maybe the Academy Awards voters understood this key principle that escaped our porcine starlet: East and West are fundamentally different from North and South. This is certainly true for the modern enterprise datacenter architecture. When you look at an architectural diagram of a single datacenter, the Internet is at the top (North) and users at the bottom (South). In between are the DMZ and services. These services are applications, virtualized servers and databases and they communicate with each other laterally (often portrayed west to east). N-S networking is considered the traditional perimeter and the conventional home of giant firewalls. E-W is the home of virtualized services, and sometimes N-S security teams don’t get invited to play in the sandboxes. So E-W traffic can be left unguarded. But it shouldn’t be that way; network policy can be implemented quickly with the F5 load-balancers already in place. Let’s take a look at an example E-W layout. Security in an East-West Network Security Traffic is flowing from the web servers east-ward through a middleware cluster and ultimately to the database cluster at the east end. All good. There should never be traffic going from the web servers to the development network, right? Web servers are a huge threat surface: when they get hacked we don’t want the attackers to be able to get into the intellectual property in development. The same goes for the middleware network, it should only talk to the database cluster network. And connections from the database cluster should never go into the development network either. Let’s redraw the diagram with the red lines to indicate connections that we want to prevent. So how can we implement this in a way that doesn’t disrupt everything or require new hardware? Lightweight Firewall Rule for Web Apps Cluster via F5 In the example above, there is an F5 application delivery controller (ADC) in between the web applications and middleware and another in front of the database cluster. Suppose the ADCs are providing simple load balancing for the application traffic running west to east. The web servers are the most interesting section of the architecture. They accept traffic from the Internet (via the ADC) and are typically configured to use the ADC as their default gateway. About the default gateway: historically,the ADC has always passed the original client IP address to the web server for logging purposes. The web server then has to use the ADC as the default gateway when it replies back the client (otherwise the traffic would go around the ADC, and that doesn’t work for proxy and cache services). On the F5 we’ll create three VLANs and virtual server objects to represent the three types of flows that we’re looking for. web-app1 : inbound traffic to web application. middleware : eastbound requests into middleware web-gw : default gateway traffic (mostly traffic from web-pool) The web-app1 virtual server defines a single public address for inbound web traffic to our application. net vlan internet { } ltm virtual web-app1 { description "internet to web app" destination 71.237.39.99:http pool web-pool profiles { http { } tcp { } } vlans { internet } } Because the web servers are accepting routable IP addresses (see sidebar), they have their default gateways set to a wildcard virtual server at the F5. The return traffic will be matched to the incoming flows. net vlan web { } ltm virtual web-gw { description "gateway to middleware" destination 0.0.0.0:any fw-enforced-policy web-gw profiles { fastL4 { } } source 192.168.2.0/24 translate-address disabled translate-port disabled vlans { web } } Web Servers: 192.168.2.0/24 Middleware: 10. 0.0.0/8 Development: 20.0.0.0/8 Database Cluster:172.16.0.0/16 Notice the destination 0.0.0.0:any. This is necessary to allow the webservers to communicate to the outside world. But suppose that an attacker got a shell on the web-server. He could then use the wildcard server to tunnel through to the development network (20.0.0.0). Not what we want. So we define a lightweight firewall rule (fw-enforced-policy web-gw) to prevent packets from getting into the development network. security firewall policy web-gw { rules { w-to-m { action reject description "Disallow development" log yes destination { addresses { 20.0.0.0/8 { } } } } } } Here’s what that rule looks like in the GUI. We’re not specifying the source network because this is only enabled on the “web” VLAN anyway (and therefore wouldn’t be acting on other traffic). Lightweight Firewall Rule for Middleware Cluster via F5 The middleware virtual server defines a single address for the web servers to communicate to a pool of middleware servers. ltm virtual middleware { description "webapp to middleware" source 192.168.2.0/24 destination 192.168.2.202:7001 pool mid-pool profiles { tcp { } } vlans { web } } The middleware virtual server has a source network specification which will act as a firewall rule all by itself. Only traffic originating from the web network will be able to pass through to the middleware cluster. It doesn’t get much more lightweight than this. If we want to prevent connections originating from the middleware tier cluster westward to the web app cluster, we can define a global firewall rule to handle this. Note that we leave a “hole” for development to push to the web app cluster. Lightweight Firewall Rule for Database Cluster via F5 The right-hand F5 ADC will very similar to the left-hand ADC. For our simple example, we have a virtual server balancing to a single pool of database servers and they should only be accessed from the middleware. Just as we did for the web app cluster, we can use the source and destination attributes of the virtual server to create an east-bound flow. ltm virtual mid-to-db { description "middleware to database" source 10.0.0.0/8 destination 10.10.10.10:3306 pool db-pool profiles { tcp { } } vlans { middleware } } We’ll also add a global firewall rule to prevent connections originating from the database cluster back toward the middleware or development. Add one exception: every Saturday night from 8PM to midnight the database clusters will be allowed to access the Internet to pull down updates. Is that Lightweight enough for you Miss Piggy? “Hiiii-yaaah!” See how easy and lightweight that was? Much of the security enforcement is already bound into the definitions of the virtual server objects themselves, leaving us with just handful of global firewall rules. Full disclosure here: I simplified this configuration a little bit for clarity. The full configuration is larger and you’d probably have a SNAT pool in between the clusters where default gateways are used. But hopefully you get the gist that it is possible, with relatively little effort, to attach lightweight firewall rules to manage the east-west traffic in your datacenter.Full Stack Security
When talking to someone who’s spent a lot of time around F5 technology, two words always come up: full-proxy and platform. BIG-IP is the platform of services offered by a full, dual-stack proxy. The proxy yields unmatched visibility and control at every layer of the connection stack, beginning at the network level to the TCP stack, the SSL stack, and then the application layer. When architecting solutions with BIG-IP Advanced Firewall Manager (AFM), this dual-stack full-proxy design differentiates itself among other security solutions. Since AFM is fully-integrated into TMOS, the performance overhead for the DDoS and other layers 3 & 4 is very low. Unlike flow-based network firewalls, BIG-IP AFM is able to fully inspect and control the client-side TCP handshake before reassembling the request and establishing the server-side TCP connection. In this way, AFM protects not only the server-side network, but the rest of the BIG-IP platform. So far, it’s becoming clear what makes BIG-IP a full-proxy security solution, but what makes it a platform? In technology, a platform is able to provide multiple services and capabilities in a well-integrated fashion. Where AFM provides layer 3 & 4 security services, the layer 7 services fall mostly elsewhere in the BIG-IP platform. For our purposes today, we’ll focus on BIG-IP Application Security Manager (ASM) and the ability to augment the DoS-mitigation functions of AFM with greater DoS and other L7 security for HTTP-based application traffic. Almost all HTTP applications will be encrypted via TLS before too long, so let’s first take note of the SSL stack on BIG-IP. The topic of configuring SSL profiles on BIG-IP for better SSL Labs scores and stronger encryption has been covered at length on DevCentral in recent years. Since the proprietary SSL stack on BIG-IP is easy to configure to enforce good, strong encryption, any vulnerable or obsolete TLS settings on the application server environment is effectively protected. The BIG-IP crypto stack is not only hardened with the latest cryptographic standards, but it is also highly optimized for performance whether accelerated by specialized chips on BIG-IP or VIPRION hardware or virtualized on your hypervisor of choice. This provides effective protection for scaled attacks, such as SSL floods. As with all things BIG-IP, the extensibility and adaptability of iRules applies to SSL, as well. (Jason Rahm will be covering iRules extensibility for AFM later this week). Once the SSL handshake has been validated, thenext stop along the full stack is the HTTP protocol inspection. Within Local Traffic Manager (LTM), there are various HTTP profile settings for inspecting each HTTP request. Security features such as header sanitization, cookie encryption, and size/length enforcement are all available before visiting more advanced HTTP inspection and enforcement capabilities found in both AFM and ASM. Protocol level enforcement of HTTP traffic is available in AFM, providing protection such as evasion technique detection, RFC compliance checks, and more advanced blocking and alarming for different HTTP attack conditions than is found the LTM HTTP profile. These HTTP protocol security enforcements are also present in ASM, but whether they are licensed or configured via AFM or ASM, the same high performance protocol enforcement engine built into the TMOS is employed. Many of these protocol security settings are useful in environments where the a full-blown WAF policy may not be applicable, whether because the application team isn’t participating in more comprehensive policy creation or because some application flows are less-sensitive or lower priority. If more advanced L7 inspection is required, then ASM is prescribed. The inspection engine in ASM is able to evaluate each HTTP request for matching attack signatures in the entire request, including the headers, URL, parameters, and data payload. There are multiple ways to configure WAF policy on ASM, including vulnerability assessment import, automated Policy Builder, and pre-loaded policy templates. Application Security Manager is no mere WAF, though. ASM also includes an array of advanced bot detection techniques, covered on DevCentral in the past by John Wagnon. Bots can’t be effectively detected and mitigated by IP address blacklisting alone, and only a full-proxy can effectively inject the various JavaScript and other countermeasures employed by ASM. In v12 of TMOS, bot detection is further enhanced with what’s known as Proactive Bot Defense, which enables more advanced fingerprinting of potential bots. Bot detection and mitigation is vital to L7 DoS defense, as almost all L7 DoS attacks are highly-automated by attackers. When Full Stack Securityis required, the BIG-IP full-proxy security platform is uniquely positioned to provide that security with great depth of control as well as massive scale. The platform-level integration provides the scale and integration for policy to be discretely configurable at each layer, from Layer 3 all the way to Layer 7. Each layer of policy, in turn, protects the platform itself, demonstrating the efficiency of the integration found on BIG-IP.
Software Defined Transformation - Management and Orchestration with F5 Synthesis
In this article we will look at how F5 continues to deliver the Management and Orchestration solutions for deploying Application Delivery Controller (ADC) platform services. We will begin with explaining how F5 approached Management solutions and how rapidly it developed to prepare for the Software Defined transformation within customer datacenters. Having interacted with over 100 major accounts in 2014 (global Enterprises and Service Providers), I've had the privilege of sharing these ideas and validate with their feedback. As an F5 customer, this article will benefit you in understanding why Management and Orchestration is a critical pillar of the F5 Synthesis architecture. Application deployments and datacenter architectures are also rapidly evolving to a point where F5 Synthesis can help you compare the value F5 offers. As a solution delivery partner, you can learn more about how F5 integrates with OpenStack, Cisco, Vmware, and Microsoft technologies to help you deliver Software Defined Networking (SDN) and Network Function Virtualization (NFV) projects for your clients. Back in the days... F5 launched its Synthesis architecture framework for application delivery services in early 2014. It marked an important milestone for the vision defined over a decade ago. Early on, F5 focused on the application delivery services Management solution as a combination of tools aligned with the target audience. Most network administrators preferred command line interface (CLI) tools, and so F5 developed a shell interface called TMSH. Some administrators preferred a graphical user interface (GUI), and so F5 developed the Enterprise Manager solution. F5 also offered the iControl APIs for administrators not afraid to write some code to programmatically configure and deploy application delivery services. Customers have used all these tools and developed their ADC operations manual and automation scripts. I was delighted to discover how widely these tools are being used. Some customers have even built their own management interfaces (GUI) using TMSH commands and iControl APIs. Customers with scripting and development skills available within IT teams preferred using iControl and TMSH. Customers with a smaller devices footprint preferred using the Enterprise Manager solution. With this backdrop, let us now look at how our next generation Management and Orchestration platform, F5 BIG-IQ, helps our customers prepare for the Software Defined transformation within their datacenters. Fundamental shifts underway... As recent as 3 years ago, network device management platforms were considered as monolithic vendor solutions for managing their software and hardware platforms. IT teams were expected to purchase the relevant vendor management products, resulting in over 2-dozen tools deployed for managing a complex infrastructure. This is true even today, but something started to change with the talk of programmable infrastructure services. The first shift was the popularity of REST APIs. With the rise of AWS and developers being able to provision infrastructure services via APIs, IT began to research similar capabilities for existing products and solutions deployed in-house. API driven orchestration started to gain interest. As a result, IT now looks at Management as not just a pretty GUI, but a comprehensive set of REST APIs as well. In every customer meeting, I was often asked “Do you have a REST API for that?” The second shift happened when IT decided to separate the task of provisioning and managing – i.e. separating the rollout out of new infrastructure services via orchestration from performing day to day management functions. Automation and Orchestration using REST APIs is rapidly becoming the norm. Many of the customers I visited have recruited software engineers to build their next-generation automation and orchestration toolbox. They are not only using the packaged cloud management platforms (of course, with API access), but also adopting platforms like Puppet, Chef, Ansible, and sometimes developing Python and Perl based scripts. In 2012 and 2013 most of the IT conversations about SDN and NFV were focused on protocol standardization and vendor support. It was primarily a white-board discussion and getting to an architectural blueprint was not yet possible. Beginning of 2014 saw some of that change. I was asked about F5's support for OpenStack Neutron, Cisco APIC, VMware NSX and most recently, Microsoft HNV. Customers were beginning to draw the blueprints and wanted to evaluate where F5 fits. Financial budgets were being committed and IT teams were preparing to embrace SDN/NFV for bringing programmability to infrastructure services deployment. The discussion changed from protocol support to the availability of REST APIs. It seemed like IT Networking professionals were converging on choosing APIs over protocols. This fitted nicely with how F5 has approached network services programmability. F5 is committed to supporting relevant standard protocols and while they evolve, F5 will provide REST APIs to enable programming of the ADC services. I have witnessed these shifts inside most of F5’s major accounts. Their F5 BIG-IP footprints have grown significantly. With rising highly available deployments (active-standby and active-active clusters), customers are now looking for more programmatic control over the entire BIG-IP fleet for lifecycle management and rapid provisioning of services. This is different than just scripting iControl APIs based on device-by-device configuration changes. Customers are now looking to have a central control point (i.e. central authority), with orchestrated provisioning of services. Customers with large-scale global datacenter footprints also expect distributed intelligence versus centralized intelligence (more on that in a future post). Orchestration becoming mainstream... Building on the iControl API approach, F5 baked the vision for BIG-IQ Management and Orchestration to address the shifts described above. With BIG-IQ, F5 plans to transform the monolithic management product approach to a programmable platform with target audience specific components (called Modules). The unique aspect of this vision is to provide API parity for everything that an IT administrator can do in the GUI. As a result, IT can get trained on the GUI and as complexity evolves, automate tasks using the APIs. By having access to APIs, IT can also enforce separation of duties (who does what and audit actions) and implement governance policies in line with business and regulatory requirements. Trying to capture the complexity of this in Management GUIs, without APIs, is akin to fighting a losing battle. F5 knows that APIs help win the complexity war, and hence focused on providing REST APIs for everything. Furthermore, REST APIs are the key to unlock the benefits of the Software Defined transformation within datacenters. Orchestration on top of device and software provisioning helps IT transform their datacenter to a programmable infrastructure. By providing REST APIs and iApps based configuration templates, F5 enables this transformation. Further, by focusing on integrations with third party platforms like OpenStack Neutron, Cisco APIC, VMWare NSX, and Microsoft SCVMM/HNV - F5 continues to offer a flexible solution that will work with whatever SDN/NFV approach the customer chooses. It is important to highlight this aspect of F5's thinking, which separates F5 from how others think about automation and orchestration. Your key takeaway is this: F5 is committed to providing control of BIG-IP configuration and policy definitions using device specific and centralized REST APIs, enabling the kind of flexibility required for rolling out software defined application services. With BIG-IQ iControl APIs, F5 helps customers get started on automating common tasks and redeem the time spent on manual operational tasks performed week after week. With the SDN/NFV integrations for OpenStack, Cisco, Vmware, and Microsoft – F5 will continue to enable choice in how to adopt Software Defined architectures for datacenter transformation. Management under rapid development... Customers expect F5 to deliver robust management capabilities that enable ease of use for all of their BIG-IP software modules. With centralized management focus in BIG-IQ, F5 is on track to deliver on that expectation. In 2014, F5 delivered the management functions for BIG-IP device lifecycle, licensing, device monitoring, firewall policies, and configuration backup/restore capabilities. The recently launched BIG-IQ 4.5 release begins to deliver object level management for BIG-IP traffic management capabilities and better control over BIG-IP security policies. In addition to robust configuration management, customers also expect a comprehensive role based access control (RBAC) framework for implementing IT governance. With BIG-IQ RBAC, customers can begin to satisfy some of these needs. Starting today, customers can use BIG-IQ to leverage the network administrator role to create configuration objects for the entire deployment, and allow the application administrator role to control their piece of the configuration. Network administrators can also view all their BIG-IP iRules from a central location and attach/detach iRules for configuration changes. Application administrators can now control the lifecycle of their BIG-IP virtual servers, virtual IP addresses, pools, and monitor the health of those services. Security administrators can also delegate control over the firewall rules and enable visibility into how the rules are enforced. With focus on simplifying BIG-IP policy changes using iApps, BIG-IQ also helps customers catalog and deploy iApps. Customers using iApps report significant savings in provisioning and configuration rollouts across multiple BIG-IPs. Customers also expect a single pane of glass interface for their entire BIG-IP deployment across multiple datacenters. They want to see the inventory of all their BIG-IP instances (physical and virtual) and view the health monitors. F5 BIG-IQ enables that with visibility into active-standby and an active-active clusters for BIG-IP traffic management functions. BIG-IQ itself can also be deployed in a high-availability configuration using active-active and active-standby modes (depending on the BIG-IP modules being managed). F5 BIG-IQ is our long term strategic investment and the roadmap is packed with capabilities that will address established and emerging ADC services deployment scenarios. Call to action… I thank our customers for helping us jointly define and begin delivering solutions that address critical pain points. While we continue to develop BIG-IQ, you can continue to use the Enterprise Manager, TMSH, and iControl based solutions per your needs. If you need information on when to use Enterprise Manager and when to use BIG-IQ, please contact your regional sales account manager to start the conversation. We’re ready to support you in deploying BIG-IQ for addressing some of the Management and Orchestration scenarios described in this article. Please share your questions on this forum or reach out to your regional sales account manager and field services engineer. We’d love to hear from you on how we can enhance our BIG-IQ solution per your needs.
La transition vers HTTP/2, l'envisager, s'y préparer, la réaliser
HTTP/2 est désormais un standard avec son support intégré dans les browsers modernes. Les serveurs Web, proposent aussi dans leurs dernières versions, la compatiliblité avec cette évolution. Ce qu'il faut retenir est qu'HTTP/2 vient accéler le transport du contenu Web en maintenant la confidentialité à travers SSL. Un des bénéfices pour les developpeurs et fournisseurs de contenu est la capacité à se rendre compte des apports de ce protocole sans remettre en cause toute son infrastructure. Les démonstrations montrent bien les gains à travers un browser sur un ordinateur portable, choses encore plus appréciables sur les plateformes mobiles. La version 12.0 de TMOS permet de se comporter comme un serveur HTTP/2 vis à vis des clients tout en continuant à solliciter le contenu en HTTP/1.0 et HTTP/1.1 auprès des serveurs. Pour trouver des raisons de s'interesser à ce protocole, plusieurs sources d'information peuvent y aider : Making the journey to HTTP/2 HTTP/2 home
一般企業向けのF5 DDoSリファレンス アーキテクチャ
今回投稿されたブログは、F5ネットワークスのテクノロジー・エバンジェリストであるDavid Holmesのブログ投稿「The F5 DDoS Reference Architecture - Enterprise Edition」を元に、日本向けに再構成したものです。 DDoSによる攻撃は依然として続いており、現在でもDDoS攻撃に対する防御は重要課題であり続けています。すでにこのDevCentralでは、グローバル金融機関向けのDDoSリファレンス アーキテクチャを紹介していますが、一般企業にとってもDDoS攻撃対策は欠かせません。そこで今回は、一般企業（エンタープライズ）向けのDDoSリファレンス アーキテクチャを提示し、グローバル金融機関向けのDDoSリファレンス アーキテクチャとどのように異なるのかを解説します。 この展開シナリオは大量の受信トラフィックだけではなく、社内ユーザからの送信トラフィックもある程度存在することを前提にしています。 グローバル金融機関向けとの差異 グローバル金融機関向けのリファレンス アーキテクチャとは、以下の点が異なっています。 1.まず図の右上に社内ユーザ（Employees）が書き込まれており、社内ユーザから社外に対してユーザ生成トラフィックが発信されています。このトラフィックは次世代ファイアウォール（Next-Generation Firewall）、あるいはWebセキュリティを提供する何らかのデバイスを通過した後、データセンターのメインのファイアウォールから、インターネットへと出ていきます。 2.一般企業のユースケースでは、DNSサービスが攻撃防御の第1段に集約されるか、少なくとも第1段のファイアウォール マネージャによって保護されるケースが一般的です。ここに示した図では、DNSサービスがBIG-IPに集約されています。 3.グローバル金融機関向けのリファレンス アーキテクチャでも解説したように、金融機関では暗号鍵を外部ネットワークから隠すため、SSLを第2段のところで終端すべきです。しかし一般企業の場合にはそれほど厳密に考える必要はないため、自由度はより高くなります。SSLの終端場所が第1段になるか第2段になるかの可能性は、ほぼ半々になります。 4.一般企業のユースケースでは、Single-Sign OnやVDI、SSL-VPNサービスを提供するAccess Policy Manager（APM）の活用が、大きなメリットをもたらす可能性があります。これらのサービスによって、社内ユーザの利便性向上とセキュリティ強化を両立できるからです。グローバル金融機関のユースケースでは、そのメリットはそれほど顕著ではありません。 グローバル金融機関向けとの共通点 なおこのアーキテクチャの本質である、2段構成の防御という点については、グローバル金融機関向けのリファレンス アーキテクチャと共通しています。第1段ではDDoSを認識するネットワーク ファイアウォールによってネットワーク攻撃を防御し、拡張性に富んだ第2段でアプリケーション攻撃を防御します。 F5のDDoSリファレンス アーキテクチャの詳細については、新しいF5 Synthesisリファレンス アーキテクチャ サイトをご覧ください。グローバル金融機関向けのF5 DDoSリファレンス アーキテクチャ
今回投稿したブログは、F5ネットワークスのテクノロジー・エバンジェリストであるDavid Holmesのブログ投稿「The F5 DDoS Reference Architecture - Global FSI Edition」を元に、日本向けに再構成したものです。以下は、David Holmesの個人的体験談に基づいています。 皆さんは、ジョージ・クルーニー主演の「マイレージ、マイライフ（原題：Up in the Air）」という映画を観たことがあるでしょうか。1000万マイル（航空会社のマイレージ、しかも国内線だけで）達成を人生の目標にしていた男の物語です。この映画の中で主人公が「年間35万マイルも飛んでいるんだ」と語っていたことを思い出します。月までの距離が約20万マイルですから、彼はそこからさらに15万マイルも彼方へ、年間で移動していたことになります。私（David Holmes）はこの映画が大好きです。なぜなら私も同じような状況に置かれており、実は私もこの2年余りの間に、30万マイル近くを空の上で過ごしてきました。 空の上で書き上げた2段構成のアーキテクチャ 私の旅のほとんどは、著名なグローバル金融機関への訪問であり、用件はDDoS攻撃に対する彼らのチャレンジに関するものです。この取り組みがもたらした大きな成果のひとつが「F5 DDoSリファレンス アーキテクチャ（F5 DDoS Reference Architecture）」です。このアーキテクチャは、ボリュメトリック型と非対称形の両方のDDoS攻撃を防御するために最適化された、分割型のネットワーク アーキテクチャです。すでにこのアーキテクチャを実現している金融機関もあれば、構築中の金融機関、あるいは早急に構築したいと希望している金融機関もあります。 私はこのアーキテクチャに関するドキュメントを、すべて飛行機の中で書き上げ、新しい「F5 reference architecture site」に掲載しました。飛行機の中では、美人アテンダントに時折気を散らされる以外は、集中して物書きができるからです。 このアーキテクチャの本質として、DDoS攻撃に対する防御機能を2段構成にしている点が挙げられます。 第1段：ネットワーク防御 第1段の防御は、ネットワーク ファイアウォールの近くに実装します。この防御機能は、SYNフラッドやICMPフラッドといった攻撃を緩和するよう設計されている他、アクセス回線の帯域使用率が80～90％になる程度のボリュメトリック攻撃にも対応します。多くの金融機関は独自のIPレピュテーション データベース（パケットを送ってきたソースIPアドレスが信用できるか否かを識別するためのデータベース）を構築しており、DDoS攻撃を受けた際にはその情報に基づいて、ソースIPアドレスからのパケットを制御します。 このリファレンス アーキテクチャは、ネットワーク ファイアウォールがF5製品か否かを問わない内容になっています。しかしあえて言わせていただければ、F5製品ほどDDoS攻撃防御を強く意識したファイアウォールは、他に存在しません。 第2段：アプリケーション防御 第2段は、CPU負荷の大きい防御メカニズムであり、アプリケーションを意識した上で展開すべきと、F5が提唱しているものです。この種のメカニズムとしては、ログイン ウォールやWebアプリケーション ファイアウォール ポリシー、F5 iRulesを活用したダイナミック セキュリティ コンテキストがあります。またSSLの終端も、この第2段に含まれます。第２段において、特定機能に特化した専用のIDS/IPSデバイスを採用した場合には、かなりのラックスペースが専有される可能性があります。 どこでSSLを終端させるべきか このリファレンス アーキテクチャを発表した後、「第2段ではなく第1段でSSLを終端させることは可能だろうか」という質問を複数の方々からいただきました。答えは「Yes」であり、私たちのお客様の中にもそのようなケースは存在します。しかしこれらのお客様はグローバルな金融機関ではありません。グローバルな金融機関はできる限り、彼らの暗号鍵を最前線のファイアウォールの後ろに隠そうとしています。彼らの資産はインターネットの中で最も高い価値を持つ攻撃ターゲットであり、SSLの暗号鍵はその最たるものだと言えるからです。 このアーキテクチャに関する詳細は「F5 Synthesis reference architecture site」で解説しています。またこのサイトにはDDoS攻撃防御だけではなく、クラウド化やLTEローミング、サービス プロバイダー向けセキュリティなどの解説も掲載されています。 このリファレンス アーキテクチャに対する反応はポジティブなものでした。お客様はぜひとも、技術的な詳細を知りたいと言ってくださったのです。飛行機の中での執筆作業は、ジョージ・クルーニーが過ごした時間よりも、間違いなく意義のあるものでした。ところで今ふと思い出したのですが、ジョージ・クルーニー主演映画の中で私が一番気に入っているのは「ラスト・ターゲット（原題：The American）」です。ぜひご覧になってください。このDDoSリファレンス アーキテクチャを読み終える間に、ネットからストリーミングできるはずですから。BIG-IQ Grows UP [End of Life]
The F5 and Cisco APIC integration based on the device package and iWorkflow is End Of Life. The latest integration is based on the Cisco AppCenter named ‘F5 ACI ServiceCenter’. Visit https://f5.com/cisco for updated information on the integration. Today F5 is announcing a new F5® BIG-IQ™ 4.5. This release includes a new BIG-IQ component – BIG-IQ ADC. Why is 4.5 a big deal? This release introduces a critical new BIG-IQ component, BIG-IQ ADC. With ADC management, BIG-IQ can finally control basic local traffic management (LTM) policies for all your BIG-IP devices from a single pane of glass. Better still, BIG-IQ’s ADC function has been designed with the concept of “roles” deeply ingrained. In practice, this means that BIG-IQ offers application teams a “self-serve portal” through which they can manage load balancing of just the objects they are “authorized” to access and update. Their changes can be staged so that they don’t go live until the network team has approved the changes. We will post follow up blogs that dive into the new functions in more detail. In truth, there are a few caveats around this release. Namely, BIG-IQ requires our customer’s to be using BIG-IP 11.4.1 or above. Many functions require 11.5 or above. Customers with older TMOS version still require F5’s legacy central management solution, Enterprise Manager. BIG-IQ still can’t do some of the functions Enterprise Manager provides, such as iHealth integration and advanced analytics. And BIG-IQ can’t yet manage some advanced LTM options. Never-the-less, this release will an essential component of many F5 deployments. And since BIG-IQ is a rapidly growing platform, the feature gaps will be filled before you know it. Better still, we have big plans for adding additional components to the BIG-IQ framework over the coming year. In short, it’s time to take a long hard look at BIG-IQ. What else is new? There are hundreds of new or modified features in this release. Let me list a few of the highlights by component: 1. BIG-IQ ADC - Role-based central Management of ADC functions across the network · Centralized basic management of LTM configurations · Monitoring of LTM objects · Provide high availability and clustering support of BIG-IP devices and application centric manageability services · Pool member management (enable/disable) · Centralized iRules Management (though not editing) · Role-based management · Staging and manual of deployments 2. BIG-IQ Cloud - Enhanced Connectivity and Partner Integration · Expand orchestration and management of cloud platforms via 3rd party developers · Connector for VMware NSX and (early access) connector for Cisco ACI · Improve customer experience via work flows and integrations · Improve tenant isolation on device and deployment 3. BIG-IQ Device - Manage physical and virtual BIG-IP devices from a single pane of glass · Support for VE volume licensing · Management of basic device configuration & templates · UCS backup scheduling · Enhanced upgrade advisor checks 4. BIG-IQ Security - Centralizes security policy deployment, administration, and management · Centralized feature support for BIG-IP AFM · Centralized policy support for BIG-IP ASM · Consolidated DDoS and logging profiles for AFM/ASM · Enhanced visibility and notifications · API documentation for ASM · UI enhancements for AFM policy management My next blog will include a video demonstrating the new BIG-IQ ADC component and showing how it enhances collaboration between the networking and application teams with fine grained RBAC.Se protéger des IP frauduleuses grâce à IP Intelligence de F5 Networks
Le meilleur moyen de se protéger des attaques est de les contrer au plus proche - c'est à dire au moment de l'initialisation de la connection (plus communément appelé le 3-Ways-Handshake). F5 Networks propose à ses clients une souscription nommée “IP Intelligence”. Cette souscription permet au BIGIP, quelque soit le module (LTM, ASM, APM, AFM, GTM …), de pouvoir vérifier avant l’initialisation de la connexion si l’IP source est frauduleuse ou non. Pour cela, le BIGIP télécharge toutes les 5 minutes la base de données d’IP frauduleuses. Cette base de données classifie les IP sous plusieurs catégories telles que les scanners, les botnets, les proxy anonymes, les sites illégaux … Dans la vidéo ci-dessous je vous présente cette souscription et comment la mettre en place. Vous y verrez les reporting obtenus.
Thoughts from the security non-professional: don’t let your data escape
Probably the biggest IT security threat to F5 Networks is typing this blog, and probably the biggest threat to your organization is reading it. OK, I don’t mean me or you, as such. We are, after all, IT professionals and wouldn’t dream of clicking on that suspicions link or using that freebie USB stick we picked up at the trade show. But the truth is people in organizations do dumb things. Even if your network is well equipped with firewalls, IPS’ and your policies are tight, people can take their laptops home with them and do dumb things. Even if your corporate policy is strict on Anti-virus and administrative lockdown, then BYOD allows people to do, yes, dumb things. In the modern workplace it’s extremely hard to prevent hostile code entering your organization. The question is, what do you do about it? Now I’m not really a security professional. Sure, I know a few acronyms and have occasionally fumbled my way through a configuring a firewall, but I don’t consider myself an expert. I do follow the high profile events in the industry though, and it struck me there was an ongoing theme that is worth examining: It’s not what comes into your organization that really hurts you, it’s what leaves it. Credit card numbers, career ending emails, source code, it’s often what organizations lose that causes the most damage. Now I know the root cause is the bad stuff that’s got in – the malformed HTTP request, the infected laptop, misused credentials or compromised router, but if we focus all of our attention on inbound security we are missing a chance to save the day when our frontline protection fails us. The successful hack of the US retailer Target is a great example – although there are plenty more to choose from. Ignoring all the infiltration and compromise techniques used, the real damage occurred when the customer details left the store. How was this done? Well allegedly an infected exfiltration server made outbound FTP connections to external drop servers. Did the in-store Target network allow inbound FTP from the internet? I don’t know for sure, but I’m guessing not. But outbound from a more trusted to a less trusted network? Apparently so. Examining and evaluating outbound traffic can and should be a powerful security tool in mitigating a compromise. You need control over where your infrastructure is sending data, and what’s in that data. If you can successfully control and audit these two things, then you have a good chance of avoiding a lot of the damage caused by an attack. For servers in your production infrastructure, it might be possible to build whitelists and restrict traffic to just the places you know it should go. Here’s where a network firewall like BIG-IP Advanced Firewall Manager can help by placing strict controls on your egress traffic. In many cases, however, and especially for end user devices, you’re going to have to rely on some kind of reputation score or endpoint location to make a decision. That’s why I like technologies like F5’s IP Intelligence and Secure Web Gateway, they can look at where your traffic is going, and decide if that’s a good idea based on a near real-time threat database and a geographical IP address database. You get a good level of control without the need to maintain an exhaustive whitelist. What about the data itself? Standalone DLP solutions are certainly available, but there are some other options. A classic DLP solution created in an iRule is the credit card scrubber this rule examines the response form a webs erver, looks for credit card numbers and removes them (or obscures the first twelve characters), simple stuff, but powerful and fairly easy to adapt to other patterns. For a more full featured solution take a look at the DataGuard feature in our web application firewall, which does the same thing but with the benefits of supporting a wider range of content, such as Microsoft® Office documents. So while inbound security controls, monitoring software and user education are still the first line of defense, in the view of this security non-professional, outbound traffic controls need more focus - because you have a greater chance of controlling what leaves your infrastructure than what gets in.The Top Ten Hardcore F5 Security Features in BIG-IP 11.6
There are 32 main features in the 11.6 release of the BIG-IP family of products and 29 of those are security features. That’s right; 91% of the features in the 11.6 release are security-related. Many of them are hardcore, infrastructure doodads that go unmentioned in press releases. This is the blog where I’ll try to give these hardcore doodads some public attention. The selection criteria is somewhat subjective because there’s no IEEE standard for hardcore. The real difficulty with this blog entry is choosing among the 29 features to select only the Top Ten Hardcore Security Features of 11.6. Number 10: DNS Firewall Services The 11.6.0 version of GTM includes two DNS security knobs for DNS firewall services. The first is Rapid Response Mode, which instructs GTM to respond more quickly in zones for which it is authoritative and then to drop the rest. The second knob is Response Policy Zones which allows for customized handling of the resolution of domain names. With RPZ, you can filter DNS queries for domains that are known to be malicious and returns custom responses that direct those queries away from the malicious domain. Brian McHenry, one of F5’s Security Solution Architects says this about the DNS Firewall services: “The world's only wire-rate application layer DNS Firewall now integrates seamlessly with an industry standard. Add to it improvements in DNS flood protection, and the fastest DNS firewall just got faster.” To read more about the RPZ, see Jonathan George’s blog here. GTM, The Global Traffic Manager, is F5’s most senior module. It is responsible for global server load-balancing and DNS services Number 9: Hardware DDoS Integration for vCMP Guests When vCMP was first developed, each virtual instance was given a slice of access to the underlying cryptographic offload and compression hardware. This feature continues the tradition by giving each virtual instance access to the underlying network DDoS hardware. Not all platforms have the chips that do this. If you want to know which platforms have it, leave a comment and one of my lovely assistants will post a follow-up. vCMP is the virtual clustered multi-processor technology and is already about as hardcore as it gets. vCMP is F5’s answer to everyone who wants the flexibility of virtualization but the performance of F5 hardware. Number 8: Geo-location-based anomaly mitigation Imagine this conversation in the war room. “Sir, we’re being attacked by Elbonia.” “Ensign, have you blocked all the traffic coming from Elbonia?” “Um, no, sir.” “Well, make it so!” That’s a conversation that need not happen with this new feature. You can now tell ASM to automatically mitigate DDoS or brute-force anomalies by the geographic location of the source. How cool is that? The Application Security Manager (ASM) is F5’s web application firewall. This is where advanced application security happens–protection against the hackers, the OWASP Top Ten, brute force, web scraping and application DDoS. Number 7: Per-request Access Policies People who have used APM know about its power to effect clientless single-signon (SSO) for web applications. But many applications perform more than one check for authorization or authentication as you navigate further. In versions prior to 11.6, APM relied on the application code and third-party IAM solutions to enforce so-called "step-up authentication." However, with v11.6, APM is now able to make multiple interrogations of the end-user in a single session, making APM a much more powerful piece of an IAM strategy. The Access Policy Manager (APM) is F5’s combo of Identity and Access Management and SSL VPN. Everything that involves authenticating users, federating their credentials and authorization of their usage belongs to the APM module. Number 6: Identity is the Perimeter Firewall Capabilities For years, everyone has been talking about how the security perimeter is changing. One of the best security models now is to define the security perimeter around the users themselves. The new User Identity firewall feature in AFM helps you do exactly that. Now you can make firewall rules specific to users or groups of users: Source user match Source user-group match Destination user match Destination user-group match An example of when you might use this would be to create a “source user-group to IP address” to allow access to your accounting servers, but only for members of the Finance group when they are coming in from the VPN or corporate LAN. The Advanced Firewall Manager (AFM) is F5’s network firewall module. It is used in enterprises, service providers and anywhere that an ADC and network firewall consolidation make sense. AFM already leads the firewall industry in network DDoS awareness and mitigation thanks to the diligence of the AFM team, which is quietly adding power features such as these: Number 5: Generic UDP Flood Vector UDP floods are tricky. The stateless nature of UDP makes it difficult to determine if any particular packet is legitimate. Sometimes a UDP attack will have a certain signature; for example, the payload will be filled with the letter ‘A’ (so unoriginal!), but sometimes a UDP attack won’t be so easy to spot. One way to detect it is to watch for a massive spike in UDP packets. That’s the job of AFM’s new UDP Flood vector. When it detects a spike in UDP traffic at a port level, it can automatically apply mitigation. That’s not the end of the story, though. One of the heaviest users of UDP is the DNS protocol, and DNS packets have to travel all through the network. When DNS gets blocked, it appears as an outage of some kind, and the IT department starts getting calls from frustrated redditors copyeditors and other cube denizens. The UDP Flood vector can whitelist DNS traffic and allow it through, even while mitigating a UDP flood around it. The "single endpoint" sweep DoS vector can be used to rate limit DNS responders that are sending too many responses back (useful for when BIG-IP itself is the target of a reflection attack). Number 4: Flow Table Sweeper Enhancements Many denial-of-service attacks target flow-tables throughout the network. For example, one of the oldest attacks, the TCP connection flood, will overwhelm the TCP stack of a firewall or host. These days, it’s not a matter of if your table will overflow, it’s when. And what should be done about it? F5’s TMOS and other defensive systems will trigger an algorithm called a sweeper to clean out (or evict) different table entries when the table starts to get full. But how should it choose? The oldest? The least busy? The slowest? This hardcore AFM feature lets you define the methods that the flow table sweeper algorithm will employ when choosing which connections to kick out when the table approaches full. Like many of the other AFM anti-DDoS features, this one should be set based on the parameters of a current attack. If your site is getting hit with a slow-and-low attack, then let the Bias:Bytes method close all those slow connections. If you are getting weird connections from all over the globe, let the Low Priority:Geos method close connections originating from low-priority regions. The flow table eviction policies can be applied on a per-virtual-server basis. This means that each virtual server can have its own max concurrent flow quota and can have a different behavior when that quota is approached. Number 3: SSL Session Mirroring Full SSL handshakes are computationally expensive. This is one of the reasons that enterprises use F5’s LTM as SSL decryption mechanisms. Suppose you are lucky enough to have a site with a lot of SSL traffic. What if something happens and your primary ADC stops receiving traffic and the secondary has to pick up all those active connections? You want the secondary to perform cheap resumption handshakes (based off a shared session ID cache) with all the clients instead of full handshakes. You can now share SSL session ID caches across traffic groups so that failovers won’t cause massive spikes in full SSL handshakes. The Local Traffic Manager (LTM) is the base module that does all the fundamental application delivery. It also hosts all the SSL decryption code, which makes it the strategic point of control in SSL for the majority of F5 customers. Number 2: OCSP Stapling The Achilles’ heel of the public key infrastructure has always been revocation, i.e. how can the system reject certificates that have been compromised? The Online Certificate Status Protocol (OCSP) was developed to solve this problem. Interested parties can query a special OCSP server for the real-time status of a certificate. Unfortunately, as Google’s Adam Langley explains in his blog, OCSP can work for private networks, but it is suboptimal at best for a global Internet solution. OCSP Stapling is the tweak that might save the integrity of the system. LTM can now staple the certificate status into each SSL connection that it serves so that interested parties can assure themselves that the a certificate is still good. Okay, we’ve covered 9 different hardcore features so far. I know you’re thinking how could there be anything more hardcore than OCSP Stapling? Before we reveal the number one most hardcore feature, let’s have a look back at those first nine: The Top Ten Hardcore F5 Security Features in 11.6 GTM 10 DNS Firewall Services vCMP 9 Hardware DDoS integration for vCMP Guests ASM 8 Geo-location-based anomaly detection and mitigation APM 7 Per-Request Access Policies AFM 6 User-Identity firewall capabilities 5 Generic UDP Flood Vector 4 Flow Table Sweeper Enhancements LTM 3 SSL Session Monitoring 2 OCP Stapling 1 External Crypto Offloading And the number one hardcore security feature of 11.6 is… Number One: External Crypto Offloading We don’t normally trash-talk competitors (we don’t have to). But Cloudflare’s recent “invention” of what they call “Keyless SSL” had a lot of us security professionals scratching our heads. F5 had been offloading crypto to external devices such as nCipher and Thales for almost two years already. So had Amazon. Everyone who really does global SSL already knew about this technology. Maybe they are out of touch over there at Cloudflare and just doing their own thing. That’s fine. I hope they don’t try to patent that stuff, because nCipher and Thales probably got there first, years and years ago. So Cloudflare, welcome to the party. The concept is pretty simple: have one device, either on-premises or elsewhere, perform most SSL operations such as bulk decryption, but offload the private-key operations to another device. That other device can be a nCipher or Thales network-attached hardware security module (NetHSM devices) or it could be an F5 physical appliance stuffed with high-performance cryptographic chips. You can now spin up cheap, fully-virtualized services that direct traffic but don’t need possession of a high-security key. Brian McHenry would also put this feature near the top of his list. He says that external crypto offloading is “…incredibly innovative…. The applications for this technology are incredibly powerful for emerging hybrid architectures. It could enable a whole new wave of micro-architectures where SSL was previously a non-starter due to management and performance issues." Honorable Mentions Several of the features almost made the Top Ten and deserve at least an honorable mention. WAF CAPTCHA (ASM) – The World’s Best Web Application Firewall can now throw back a user challenge in the form of a CAPTCHA if it suspects that user of trying to brute force or Dos a service. TLS Extension support for NPN and ALPN (LTM) – These two critical SSL/TLS extensions are now supported. Next Protocol Negotiation (NPN) and the Application Layer Protocol Negotiation (ALPN) help support Google’s SPDY protocol. Conclusion So there we are: a dozen hardcore security features in 11.6. If you feel inspired and want to learn more, download 11.6 today and start playing with it. See the 11.6 Release Notes for the complete list of security (and other) features and of course, stay hardcore.
