Check Point vsec for Microsoft Azure

Content 1 INTRODUCTION... 3 2 TEST DRIVE OVERVIEW... 4 3 TEST DRIVE... 5 3.1 REVIEW THE VSEC PRODUCT INFORMATION AND USE CASES... 5 3.2 INFORMATION FOR ACCESSING THE TEST DRIVE ENVIRONMENT... 5 3.3 CONNECTING TO THE TEST DRIVE ENVIRONMENT... 6 3.3.1 Using the Windows Remote Desktop Client... 6 3.3.2 Using an Existing Check Point R77.30 SmartConsole Client... 8 3.4 REVIEW THE SECURITY POLICY... 8 3.5 VERIFY NORMAL WEB TRAFFIC... 11 3.6 BLOCK AN SQL INJECTION ATTACK... 12 3.7 BLOCK ACCESS TO SOCIAL NETWORKS... 17 4 VSEC FOR AZURE USE CASES OVERVIEW... 22 5 SUPPORT... 22 Figures Figure 1 Check Point vsec for Microsoft Azure Test Drive Environment... 4 2017 Check Point Software Technologies Ltd. All rights reserved Page 2

1 Introduction Welcome to Check Point vsec for Microsoft Azure test drive! Check Point vsec test drive for Microsoft Azure enables customers to rapidly try out vsec enterprise security gateway features deployed on a virtual instance inside a Microsoft Azure IaaS (Infrastructure as a Service) virtual cloud. This test drive will allow you to experience the capabilities of the vsec gateway in action using a real web server app, simulated attack vectors, and verification of activity in event logs. Why do I need vsec for Azure when the cloud is already secure? Check Point vsec allows you to protect your apps and data deployed in Azure. As you may well know, when you deploy a server in Azure configured with a public facing IP (even a private IP with NAT allowing for Internet access), it is exposed to cyber-attacks from the Internet, just like any server deployed in an on premise environment. Cloud providers provide cost efficient computing resources but only secure the infrastructure layer. Check Point vsec allows you to secure the higher layers (network layer up to application layer) with advanced multi-layer security in order to gain visibility into traffic and threats as well as detect and prevent attacks inside and outside your cloud network and demonstrate compliance. Additionally, a perimeter based security gateway approach makes it easier to protect multiple virtual machine instances (with unknown security posture, software, and patch levels) in a highly dynamic cloud environment where VMs are spun up and removed constantly. It is the customer s responsibility to protect his data and apps in the cloud. Activities included in this Test Drive At the end of the test drive, you will have accomplished the following: Remotely access and navigate the SmartConsole management user interface (UI) to provision and monitor the vsec security gateway Enable internet/public facing app (web server) by provisioning a security policy and verify correct operation of the web server Simulate an SQL attack, watch it succeed, and then block the attack by provisioning Intrusion Prevention (IPS) functionality and verify correct operation in the SmartEvent logs Block all access to social networks (i.e. Facebook/LinkedIn/Twitter) by enabling Application and URL Filtering and verify correct operation using SmartEvent logs If you wish to purchase and deploy vsec for Azure immediately in either PAY as you Go (PAYG) or Bring Your Own License (BYOL) licensing model, please visit the vsec listing on Azure Marketplace which contains ARM templates for rapid single click provisioning and deployment. A reference architecture is available at: https://supportcenter.checkpoint.com/supportcenter/portal?eventsubmit_dogoviewsolutiondeta ils=&solutionid=sk109360&partition=general&product=vsec Please note that Check Point vsec is fully integrated with Azure Security Center as well, to automate and orchestrate the deployment. Follow the instructions below to begin your test drive. Enjoy your journey! 2017 Check Point Software Technologies Ltd. All rights reserved Page 3

2 Test Drive Overview This test drive will have you working on securing a single tier app environment where tier one is a web server deployed inside Azure cloud behind the Azure load balancer. This simulates a realworld scenario where the web server hosts dynamic content from the cloud but needs to be secured with advance threat protection using a virtual enterprise security gateway. In this scenario, all inbound/outbound (i.e. North/South) traffic to the web server is secured by the vsec gateway. The test drive environment consists of the following components: Figure 1 Check Point vsec for Microsoft Azure Test Drive Environment An Azure Virtual Network with the following subnets: A Gateway external subnet (10.0.0.0/24) A Gateway internal subnet (10.0.1.0/24) A Web Server Subnet (10.0.2.0/24) The test drive has 3 virtual machines: A Linux machine A Windows machine A Check Point vsec gateway 2017 Check Point Software Technologies Ltd. All rights reserved Page 4

The Linux machine is pre-configured as a web server listening on TCP port 80. The Windows machine is pre-installed with the Check Point SmartConsole (R77.30) Graphical User Interface clients. The Check Point vsec gateway has two interfaces attached to external and internal subnets. The Windows machine is attached to external subnet. The Web Server is attached to the web server subnet. In addition, an Azure load balancer is set up to receive HTTP traffic on a dedicated public address and forward it to the Check Point vsec security gateway. The Check Point vsec Security gateway is pre-configured with security and Network Address Translation (NAT) policies to receive and forward this traffic. 3 Test Drive Note: It can take up to 15 minutes for your environment to be built. 3.1 Review the vsec Product Information and Use Cases While your test drive environment is being built, you can: Read the short Check Point vsec for Microsoft Azure Solution Brief http://www.checkpoint.com/downloads/product-related/solution-brief/sb-vsec-azure.pdf Visit the Check Point vsec for Microsoft Azure page https://www.checkpoint.com/products/vsec-microsoft-azure/ Review the key use cases described in section 4 vsec for Azure Use Cases Overview at the end of this guide. 3.2 Information for Accessing the Test Drive Environment When you launch the test drive, you will receive an email containing information that will allow you to connect to your environment. This email includes: The user names and password needed to authenticate to the Windows machine and the Check Point vsec Gateway The public address of the gateway The public address of the Windows machine The URL of the protected web application The same access information is also available in the Test Drive page. In this Test Drive, we will be using Check Point SmartConsole, a group of Windows based graphical user interface (GUI) clients, to manage and monitor the security policy of the Check Point vsec gateway. 2017 Check Point Software Technologies Ltd. All rights reserved Page 5

3.3 Connecting to the Test Drive Environment You have two options to access the Test Drive: You can use the Windows machine with the pre-installed clients. o Go to section 3.3.1 Using the Windows Remote Desktop Client. Alternatively, if you already have Check Point SmartConsole R77.30 installed on your computer, you can use it to directly connect to the public address of the Check Point vsec gateway. o Go to section 3.3.2 Using an Existing Check Point R77.30 SmartConsole Client. 3.3.1 Using the Windows Remote Desktop Client If you do not have the Check Point R77.30 SmartConsole client installed, you can use the Windows machine in the Test Drive environment where it is already pre-installed. To connect to the Windows machine in the Test Drive environment: Open a Remote Desktop Connection client (Start -> mstsc in Windows). Click on For Computer, use the Windows server address from your My Test Drives section or the Windows IP address you received in your Test Drive email. For User name, use \vsec (note the leading \ to avoid the use of your corporate domain). Click Connect. 2017 Check Point Software Technologies Ltd. All rights reserved Page 6

Under password, enter the Windows server password from your My Test Drives section or the password you received in your Test Drive email. They are the same. Click OK. After you login to the Windows machine, locate, and launch the SmartDashboard R77.30 client in the top left: Log in with the Gateway password from your My Test Drives section or the password you received via email. o The Gateway username is admin as stated in your My Test Drives section and the email you received. o The IP address is 10.0.0.10 (the external private address). o Click on Login, and approve the fingerprint: Proceed to section 3.4 Review the Security Policy. 2017 Check Point Software Technologies Ltd. All rights reserved Page 7

3.3.2 Using an Existing Check Point R77.30 SmartConsole Client If you already have the Check Point R77.30 SmartConsole client pre-installed on your computer, you can use it to directly connect to the Check Point vsec Gateway. Open Check Point R77.30 SmartDashboard. Log in with the Gateway password from your My Test Drives section or the password you received via email. o The Gateway username is admin as stated in your My Test Drives section and the email you received. o Use the public gateway IP address from your My Test Drives section or the email you received. o Click on Login, and approve the fingerprint: 3.4 Review the Security Policy Now that you are connected to the Check Point vsec Security Gateway for Azure, let s examine the security policy. Go to the Firewall Tab, and click Policy. 2017 Check Point Software Technologies Ltd. All rights reserved Page 8

Review the firewall security policy. The table below details the purpose of the security policy rules from above: Rule Purpose 1 Allow HTTP connections to the web server 2 Allow any connection originating from the web subnet 3 Allow SSH connections to the gateway 4 Allow SmartConsole connections to the gateway 5 Allow HTTPS connections to the gateway 6 Allow pings 7 Drop all other traffic Note: All rules have logs enabled. Now let s examine the NAT rules. Go to the Firewall tab and click NAT. 2017 Check Point Software Technologies Ltd. All rights reserved Page 9

Review the firewall Network Address Translation (NAT) policy: The table below details the purpose of the NAT policy rules from above: Rules Purpose 1-2 Automatic rules, can be ignored 3-4 Hide connections originating from the web subnet behind the gateway s address 5 Translate health check connections arriving to the gateway on port 8081 to the private address of the web server while hiding to source behind the gateway to ensure that returning packets are sent to the gateway 6 Translate connections arriving from the Internet to the gateway on port 8081 to the private address of the internal load balancer Review the automatically created network objects: 2017 Check Point Software Technologies Ltd. All rights reserved Page 10

Open the SmartView Tracker client application. We will be using this application to view logs. You can do this directly from the SmartDashboard application as shown below. In the next sections, you ll complete tasks related to cloud security management activities. 3.5 Verify Normal Web Traffic In this scenario, you will verify normal web traffic. Use a browser to connect to the URL in your My Test Drives Access information Step 1 and that you received via email (Web Server URL). Click on the first Test button. 2017 Check Point Software Technologies Ltd. All rights reserved Page 11

This will generate a standard web request to the following URL: http://[web-server-address]/vsec.jpg This connection should be allowed and the status should change to Success as shown above. (Optional) You can verify this manually by adding /vsec.jpg to the URL in your My Test Drives Access information Step 1 (or from the email you received (Web Server URL)) and browsing to it. 3.6 Block an SQL Injection Attack Now you will simulate an SQL Injection Attack, configure the Intrusion Prevention (IPS) functionality in order to block the attack, and then view the generated logs. Click on the 2 nd Test button (Block SQL injection attack). This will simulate an SQL injection attack by requesting the following URL: http://[web-server-address]/cgi-bin/sql-injection/id=concat Since we have not set up the Intrusion Prevention (IPS) functionality, this attack will not be blocked. 2017 Check Point Software Technologies Ltd. All rights reserved Page 12

(Optional) Verify this manually by adding /cgi-bin/sql-injection/id=concat to the URL in your My Test Drives Access information Step 1 (or from the email you received (Web Server URL)) and browsing to it. http://[web-server-address]/cgi-bin/sql-injection/id=concat In order to block the above attack, you need to configure IPS (Intrusion Prevention System) functionality. In SmartDashboard: Click on the IPS tab at the top of the window. Click on Protections in the left column In the Protections pane, type sql in the Look for box. 2017 Check Point Software Technologies Ltd. All rights reserved Page 13

Click on the SQL Injection protection at the bottom of the table. Double click on Inactive in the Default_Protection column. In the Protection Settings windows, select the Override IPS Policy with button, select Prevent from the pull-down menu, select Apply to all HTTP Traffic, and click OK. 2017 Check Point Software Technologies Ltd. All rights reserved Page 14

Click on Install Policy in the top menu bar to install the newly modified policy. Click on OK to install the IPS policy on the vsec gateway. Wait for the policy installation to complete and click Close. Launch the SQL attack again to verify IPS functionality. On the Web Server page: Click on the 2 nd Test button again (Block SQL injection attack). 2017 Check Point Software Technologies Ltd. All rights reserved Page 15

This time, the attack should be blocked. (Optional) Test this manually by adding /cgi-bin/sql-injection/id=concat to the URL in your My Test Drives Access information Step 1 (or from the email you received (Web Server URL)) and browsing to it. http://[web-server-address]/cgi-bin/sql-injection/id=concat In SmartView Tracker: View the generated log by navigating to the IPS blade view under Network Security Blades and double-clicking All. You should see an SQL attack log similar to this: 2017 Check Point Software Technologies Ltd. All rights reserved Page 16

Double click on the log record to see more information. 3.7 Block Access to Social Networks In this activity, you will simulate access to social networks, configure Application & URL Filtering functionality in order to block access to social networks, and then view the generated logs. On the Web Server page: Click on the 3 rd Test button (Block access to social networks). This will cause the web server to communicate with various social networks web sites. Since we have not yet set up Application Control & URL Filtering, this traffic will not be blocked. 2017 Check Point Software Technologies Ltd. All rights reserved Page 17

In SmartDashboard: Go to Application & URL Filtering tab and click on Policy in the left column. Add a new rule by clicking on the Add bottom button. This will add an automatically created rule. In the Application/Sites column, click on the + to use the widget. Type social networking in the box, check the Social Networking category, and click OK. 2017 Check Point Software Technologies Ltd. All rights reserved Page 18

In the Track column, change the option to Complete Log The final rule should look like the following: Click on Install Policy in the top menu bar to install the newly modified policy. Click on OK to install the Application & URL Filtering policy. 2017 Check Point Software Technologies Ltd. All rights reserved Page 19

Wait for the policy installation to complete and click Close. On the Web Server page: Click on the 3 rd Test button again to simulate access to social networks. This time, access to social networks should be blocked: In SmartView Tracker: View the generated log by navigating to the Application and URL Filtering view under Network Security Blades and double-clicking All. 2017 Check Point Software Technologies Ltd. All rights reserved Page 20

You should see several logs indicating that a connection was opened from the web subnet to social network web sites similar to this: Double click on one of these log record to see more information. 2017 Check Point Software Technologies Ltd. All rights reserved Page 21

Congratulations! You have completed the activities in the Check Point vsec for Microsoft Azure Test Drive. Feel free to keep exploring this environment. Thank you! 4 vsec for Azure Use Cases Overview Key use cases of vsec for Azure include: Advanced security protection of your internet/public facing apps hosted in Azure using perimeter gateway Hybrid cloud by creating site-to-site secure VPN tunnel between your on premise network and cloud network allowing secured communications between on premise users & applications and cloud applications & infrastructure Secure remote access to the cloud apps for mobile users using point-to-point secure tunnel allowing mobile users to talk to your cloud apps Intersegment security protection between app tiers inside your cloud preventing the lateral spread of threats between servers inside your cloud Achieve high availability using multiple gateways deployed in a cluster Auto-scaling by automatically deploying multiple instances of security gateway using an elastic load balancer Provision security policy using Azure cloud objects like VM instance names and network security groups/tags Review event logs with cloud objects like VM instance names and network security groups 5 Support Please contact your Check Point or Microsoft Azure sales team for more information about this Test Drive and Check Point vsec for Azure. 2017 Check Point Software Technologies Ltd. All rights reserved Page 22