klare sicht im azorenhoch security best practices für ... · every vm is deployed inside a vnet...
TRANSCRIPT
© Copyright Fortinet Inc. All rights reserved.
Klare Sicht im Azorenhoch – Security Best Practices für Netzwerkverkehr in MS Azure
Gabriel Kälin – Systems Engineer, Fortinet
MEET SWISS INFOSEC! 24. Juni 2019
2
Warum ist Netzwerkverkehr in Azure anders?
INSTANCE A
10.0.0.10
INSTANCE B
10.0.0.11
1Who has 10.0.0.11
Tell 10.0.0.10
MAPPING
SERVICE
2
Host Hypervisor A intercepts the packet
And asks mapping service:
Who has 10.0.0.11 for VNETx Customer A
HOST HYPERVISOR AHOST HYPERVISOR B
INSTANCE A
CUSTOMER B
10.0.0.10
INSTANCE B
CUSTOMER B
10.0.0.11
3The Mapping Service tell Host Hypervisor A
The 10.0.0.11 you are looking for is on
Host Hypervisor B
4
Host Hypervisor A encapsulates the
packets and forwards to target Host
Hypervisor B
5
Host Hypervisor B checks with mapping
Service to verify source hypervisor
matches
6
Host Hypervisor B Forward packets to
Target instance
MAPPING
SERVICE
CACHE
MAPPING
SERVICE
CACHE
3
Single FortiGateMAIN – 10.100.0.0/16
RT-public
NSG1
FGT-PIP
.1.0/24
RT private
0.0.0.0/0 to 10.100.2.4 (NVA)
RT public
public
.2.0/24private
0.0.0.0/0 to Internet
.5
.4
.4
Ubuntu
FGT
RT-private
NSG2
4
IPSEC to TRANSIT VNETSVC1 – 10.101.0.0/16
.4
.1.0/24
RT1
SVC2 – 10.102.0.0/16
.4
.1.0/24
RT1
TRANSIT – 10.100.0.0/16
.2.0/24
RT2 NSG1
RT 1
0.0.0.0/0 via 10.100.2.4
RT3 NSG1
FGT Public IP
.1.0/24
RT 3
0.0.0.0/0 via Internet
10.0.0.0/16 via IPsec VPN
RT 2
.4.4 FGT
On-Premise – 10.0.0.0/16
IPSEC
0.0.0.0/0 via 10.100.2.4
5
Best Practice – Focus on flows
VNET1 VNET2
DCREMOTE SITE
INTERNET
SUBNET A SUBNET B
CH2CH1
RH1 DC1
CH3
IH1
LEGEND
IH1 – Internet Host 1
CH1 – Cloud Host 1
CH2 – Cloud Host 2
CH3 – Cloud Host 3
DC1 – Data Centre Host 1
RH1 – Remote Host 1
12
3
4
5
6
78
9 A
6
Micro-segmentation with AzureUser Defined Route (UDR) and FortiGate NGFW
• Policy Enforcement Connector
• Management / Analytics
• Next Generation Firewall
• Compliance Automation
• Advanced Threat Protection
• VPN IPSec Tunnels
• Web Application Firewall
• Identity and Access Management
• Cloud Access Security Broker
• Container Security
• Denial of Service Protection
Enterprise Data Center /
Branch Office
VMs
Azure
Function
Azure ARMTerraformPython
• Block lateral threat propagation in East-West direction
• Comprehensive protection in N-S direction
• Advanced security (L7 Firewall, IPS, and ATP) for all traffic paths
• Security workflows that adapt to deployment changes
• Auto-provisioning of security services across all platforms
Private subnet
10.0.2.0/24
FortiGate
Private
Interface
10.0.0.0/16
10.0.2.4
Destination Next Hop
Web subnet
App subnet
DB subnet
10.0.2.4
10.0.2.4
10.0.2.4
Web
UDR
Web
NSG
Web Tier 10.0.3.0/24
App Tier 10.0.4.0/24
DB Tier 10.0.5.0/24
10.0.1.4
Public subnet
10.0.1.0/24
Public
Interface
Internet 10.0.2.4
Direction Priority Source Destination Action
Inbound 2000 Internet Web Subnet Allow
Inbound 4000 Any Any Deny
Outbound 2000 Web Subnet App Subnet Allow
Outbound 4000 Any Any DenyExpress
Route/IPSec
7
• Policy Enforcement Connector
• Management / Analytics
• Next Generation Firewall
• Compliance Automation
• Advanced Threat Protection
• VPN IPSec Tunnels
• Web Application Firewall
• Identity and Access Management
• Cloud Access Security Broker
• Container Security
• Denial of Service Protection
Azure Function –Auto-Scale Handler
Cosmos DB –
VMSS Member
Repository
• Scale up and down capacity based on changing traffic volume
• Integrated with Azure VMSS and Azure Load Balancer
• Take advantage of Azure Internal Standard SKU Load Balancer to load balance outbound traffic
• Enable HA port to allow all protocols/ports
• FortiGate NGFW integrated with Azure Security Center
• Automatically failover when NGFW instances become unhealthy
Elastic Load Balancing Sandwich with FortiGate NGFW and Azure Virtual Machine Scale Set (VMSS)
Load Balancer Front End
57.77.124.9966.44.4.11
FGT VMSS
UDR
10.0.2.510.0.2.4
Apply SNAT at each FGT for both inbound and outbound
Public subnet 10.0.1.0/24
Private subnet 10.0.2.0/24
Protected subnet 10.0.3.0/24
Standard SKU
Internal Load
Balancer (HA Port)
10.0.0.0/16
10.0.2.7
10.0.2.7
10.0.2.7
Internet
(0.0.0.0/0)
Private subnet
Destination Next hop
8
Cloud DMZ with Internal Segmentation – single vnet
9
Microsoft Reference Architecture:Hub-Spoke network topology in Azure
https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/shared-services
10
Cloud DMZ Hub-Spoke Topology with DMZ vnet
▪ DMZ vnet can also be
treated like a special
spoke
▪ Further, DMZ workloads
could actually be further
spokes to the DMZ for
DMZ segmentation (not
depicted here)
11
• Weil alle Hosts in einem vnet und peered vnets direkt kommunizieren können
• Segmentierung mittels unterschiedlicher vnets und vnet Peering
• Sorgfältige Verwendung von User Defined Routes (UDR) und Network Security
Groups (NSG)
• Schlanke Linux Hosts in jedem Subnet helfen, die Segmentierung zu verifizieren
• Auf einfache zukünftige Skalierbarkeit (scale out) achten
• Hub-Spoke Topologie verwenden
• Active-Active FortiGate Setup mit Load Balancern verwenden
• FortiManager für synchronisierte Policies auf den FortiGates verwenden
• Connectoren in FortiGate bzw. FortiManager verwenden
• Direkte Internet-Verbindung aufs Minimum reduzieren.
• VPN als sicheren Admin Zugang (Two-Factor Authentication, Certificate)
Best Practices Übersicht
12
A Propos Klare Sicht: FortiCASB Cloud
API
FortiCASB
Cloud Admin
Security Architect
▪ Cloud based SaaS Service
▪ Get visibility into risks in your
public cloud deployment
13
FortiCASB – Traffic Analysis and Investigation
15
▪ Fortinet’s Azure start page» http://www.fortinet.com/azure
▪ FortiGate in the Azure marketplace (with test drive or first 30 days free for PAYG version)» https://azuremarketplace.microsoft.com/en-us/marketplace/apps/fortinet.fortinet-fortigate-singlevm
▪ FortiGate HA template in Azure marketplace» https://azuremarketplace.microsoft.com/en-us/marketplace/apps/fortinet.fortigatengfw-high-availability?tab=Overview
▪ Custom Templates for Azure deployments
» https://github.com/fortinetsolutions/Azure-Templates
▪ Cloud landing page on Fuse
» https://fuse.fortinet.com/p/fo/si/topic=601
Azure Resources
16
https://docs.fortinet.com/vm
17
Enterprise Data Center / Branch Office
VMs
Cloud Access
& VPN
VPN / SD-WAN
• Policy Enforcement Connector
• Management / Analytics
• Next Generation Firewall
• Compliance Automation
• Advanced Threat Protection
• VPN IPSec Tunnels
• Web Application Firewall
• Identity and Access Management
• Cloud Access Security Broker
• Auto Scaling Security
• Denial of Service Protection
Policy
Enforcement
Connector /
Management
and Analytics
• Single Policy Set across all deployments
• Leverage metadata instead of traditional IP in security policies
• Automated workload and metadata discovery
• Centralized management & analytics across deployments
• Intuitive visibility
• Automated VPN provisioning for multi-cloud connectivity
• Quarantine infected workloads automatically
• Block lateral threat propagation in East-West direction
• Comprehensive protection in North-South direction
• Advanced security (L7 Firewall, IPS, and ATP) for all traffic paths
• Security workflows that adapt to deployment changes
• Auto-provisioning of security services across all platforms
Multi-Cloud Security Reference Architecture
MPLS
Internet
Remote
Workforce
Container Security
Cloud Sandboxing
Azure
ARM
Python
AWS
CFT
Terraform
Azure ElementsRessource groups, VNET, NIC, Instances, Route Tables, Network
Security Groups…
19
▪ A logical container with Resource Manager that hold all related
resources for an application of service.
▪ Resource Groups (RG) represent the highest “logical level” within
Azure Beneath Subscription
▪ All resources in Azure will belong to a Resource Group which
belong to subscription.
▪ Resource Groups require:
» Subscription, Location
Resource Groups
20
▪ A VNET is a virtual network dedicated to your AZ account. It is logically isolated from
other virtual networks in the AZ Cloud
» Default VNET allows internet access
» Each default subnet is a public subnet
» Each instance that you launch into a default subnet has a private IPv4 address and a public IPv4
address.
» All elements within a VNET can communicate directly with each other, even if they are in different
subnets (by default)
▪ You can create a non-default subnet, in which case:
» Each instance that you launch into a non-default subnet has a private IPv4 address, it has no public
IPv4 address
▪ Route Tables with NONE as 0.0.0.0/0 destination will block internet access by default.
» These instances can communicate with each other, but can't access the internet
▪ VNETs Require:
» Subscription, Resource Group, Location, Name and CIDR Block + 1 Subnet
Azure VNET
21
▪ VMs and VM Sizes
▪ Route Tables (UDR)
▪ Network Interfaces
▪ Network Security Groups
▪ Public IP Addresses
▪ VNET Peering
▪ Availability Sets and Availability Zones
VNET Networking Elements You Will Encounter
22
▪ An NIC is a virtual network interface
▪ NIC attributes (IP/MAC/NSG…) follow it as it is attached or detached from an instance
▪ When you move a NIC, network traffic is redirected to the new instance
▪ Each instance in your VNET has a default network interface (the primary network interface)
that is assigned a private IPv4 address from the IPv4 address range of your VNET. You
cannot detach a primary network interface from an instance
▪ A VM has a maximum number of NICs based on its VM Size (more later)
▪ A NIC must have the following values:
» Name, VNET, Subnet, Private IP Assignment, Resource Group and Location
Network Interfaces (NICs)
23
▪ Every VM is deployed inside a VNET
▪ And requires Storage/NIC and Memory/Compute
▪ The size of CPU/Memory and base storage is limited by instance size and series.
▪ Each series is optimized for a different purpose.. Ie compute/memory/IO etc.
▪ Instance Size will dictate the maximum number of NICs
▪ See here for more : https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-
sizes-specs
VMs and VM Sizes
24
▪ Public IPs can exist without being attached to anything. They are a static or dynamic IP assigned to your Subscription and RG
» 2 SKUs – Basic and Standard▪ Basic are OPEN by default
▪ Standard REQUIRE a Network Security Group to allow access
▪ Basic are NOT Zone Redundant – Standard are Zone Redundant by default.
▪ Standard MUST be static and not dynamic
» Used for communication with Internet and public facing Azure services
▪ Private IP Address are used for communication within VNETs and on premises networks over VPN or ExpressRoute. And are always attached to a parent NIC as an IP Configuration. A Single NIC may have multiple IP Configurations
▪ Note: Matching SKUs for use with a load balancer is REQUIRED. Failure to do so may result in significant issues.
Public and Private IPs
25
▪ Not all IPs are created equal
▪ Dynamic Public IPs are free
▪ Static Public IPs are charged at a rate of approx. $0.005/hour
▪ Deleting a Static Public IP means maybe never seeing that IP
again.. So be certain before you do.
▪ NOTE: Don’t leave these lying around .. They add up.
▪ PUBLIC IPs belong to a Subscription and Resource Group
A note about Public IP Pricing
26
▪ Each subnet in your may have a Route Table assigned to it.
▪ Route tables live independently of the subnets they are attached to.
▪ A subnet can only be associated with one route table, but you can allocate multiple subnets to the same route table
▪ Rules
» Your VNET has an implicit router
» Each subnet has a “invisible route table” visible through effective routes which is build out of system routes.
» You can create additional custom route tables for your RESOURCE GROUP.. They are not VNET specific.
» Every route table contains a local route for communication within the VNET over IPv4.
Route Tables (aka User Defined Routes – UDRs)
27
▪ Azure is hosted in multiple locations worldwide. These locations are composed of Locations
▪ Each Location is in a separate geographical region. EG UK West vs UK South
» Each region has multiple, isolated locations known as Availability Zones
» Not all regions support availability zones yet. Not all services support availability zones
yet either.
» Interzone data bandwidth charges do apply.
▪ Inter-region communication incurs a bandwidth cost
VNET – Regions & Availability Zones (AZ)
28
▪ A VNET peering connection is a networking connection between two VNETs that enables you to
route traffic between them using private addresses
▪ Instances in either VNET can communicate with each other as if they were within the same
network OR depending on peering permissions:
» Be permitted to route through a peer
» Use a peers remote gateway (i.e. VPN/ExpressRoute)
▪ You can peer across subscriptions and locations but this adds significant complexity.
▪ There is a bandwidth cost for traffic across a peer but it is very small
▪ These are extremely highly available by design.
▪ A Single VNET may have multiple peers
Azure VNET Peering (It’s pretty neat)
29
▪ A security group acts as a stateful virtual firewall that controls the traffic for one or more
instances OR subnets
▪ SG are associated with network interfaces or subnets.
▪ By default, SG’s allow all local VNET traffic and Load Balancer traffic only.
» SG’s are stateful
» Source may be IP/ServiceTag or ASG (like AWS SG)
» Support Protocols for rules are TCP/UDP
▪ Instance will often be assigned a specific SG from the marketplace when deployed. Many
however will not. An instance without a security group “should” allow traffic but this is not
strictly true.
▪ If things are NOT working, always check SG’s first!
Security – Network Security Groups (NSG)