Skip to main content

Tejas Jain - GCP Notes#2



Virtual Private Cloud (VPC)

VPC Networks

Global resources (not associated with any zone) and include subnets, routes and firewall rules

VPC Networks do not have any IP addresses associated with them (unlike AWS)

Resources within a VPC can communicate with one another using the internal IP addresses

By default, resources in two different VPCs cannot communicate with each other. The communication can be facilitated by VPC Network Peering

VPC networks support IPv4 unicast traffic only. They do not support broadcast, multicast or IPv6 traffic within the network

 

VPC Subnets

Subnets represent VPC Network partitions using one or more useful IP address ranges

Subnets are regional resources. Each subnet comprises of a range of IP addresses. These can be primary IP ranges or secondary IP ranges (alias)

A network must have at least one subnet before it can be used

More than one subnet per region can be created

VPC Network supports following modes of subnet creation:

    Auto Mode VPC networks

        Create subnets in each region automatically

        Adds new subnets automatically, if a new region becomes available

        Can be switched to custom mode VPC networks

    Custom Mode VPC Networks

        Start with no subnets, giving full control over subnet creation

        Cannot be switched to auto mode VPC Networks

        These are better suited for the production environments

   

Changing IP address range of a Subnet

    It is possible to expand the IP address range of a subnet by modifying the subnet mask. This is usually required in the production environments when the existing ranges are insufficient to handle IP address allocations for the new devices.


VPC Routes

    Provide path for packets egressing out of the instances (sources).

    Comprises of a destination prefix (the packet's ultimate destination) and next hop (where should the packet go first, to reach its final destination)

    Routes are defined at the VPC network level but implemented at each VM instance level

    Route Learning Mechanism: Whenever changes are made to the VPC routes (add / modify / delete), GCP notifies the changes to the VM instance's internal controller that keeps track of all the applicable routes configured at the VPC level. The controller ensures that the outgoing packet destined to a particular destination is routed to the configured next hop.


    Route Types

        system-generated routes (applied at the VPC level to all the instances)

            default - send traffic from instances to the internet. These routes can be removed or replaced

            subnet routes - route traffic among its subnets and updated automatically by Google cloud (in response to subnet additions, deletions etc.)


        custom routes

            Static routes created manually or dynamic routes maintained automatically by the Cloud Routers

            Can be applied to all the instances using network tag


VPC Private Access Options

    VPC Private Access allows VM instances with internal IP addresses (inside a VPC) to communicate with APIs and services

    Private Google Access

        Allows VMs to connect to the external IP addresses used by Google APIs and services

        This is to avoid assigning public IPs (i.e. direct external internet access) to the Google Cloud (VPC) resources just for accessing Google APIs

        Private Google Access is configured on the subnet level (not VPC level) and is used by the VM's Network interface

        Provides routing options as follows:

            Use default route with the next-hop being default internet gateway and it provides a path to the default domains, private.googleapis.com and restricted.googleapis.com

            Use custom static routes, each having a more specific destination, and each using the default internet gateway next hop

    

    Private Services Access

        Private connection between VPC network and Google owned network or 3rd party provider network

        Enables resources in a VM network to communicate with Internet resources using private IP addresses (without providing direct internet access to the VPC resources)


Shared VPC

    Allows an organization to have a centralized (shared) VPC in a single project and connect resources from multiple other projects to this centralized VPC

    Shared VPC (sort of, hub) project designated as Host project

    One or more projects connecting the Host project are designated as Service projects

    Allows enforcement of decentralized administration. Service project admins manage their respective service projects and the Host project (Shared VPC Admin) admin (sort of, super admin) manages the Host project

    A host project contains one or more Shared VPC networks and attaches one or more service projects to it

    A service project attaches to the host project and leverages the services offered by Shared VPC, of the host project

    Rules of Attachment

        A project cannot be both host and service project --> This prevents daisy chaining projects in a tree-like hierarchy.

        In case of multiple host projects, each service project can only attach to a single host project

        A project that does not participate in Shared VPC is called standalone project

        Shared VPC Networks can comprise of subnets either in auto or custom mode

        Host and Service Projects are attached at the Project level

    


Comments

Post a Comment

Popular posts from this blog

MITRE ATT&CK - Kerberos Vulnerabilities and Security

From the previous post, the summary of Kerberos authentication process is as below: For the initial authentication, the user’s client machine sends a request to the KDC  Authentication Service (AS) . The request includes details like the user’s username, and the date and time. All information except the username is encrypted using the hash of the user’s password. The KDC AS uses the username to look up its copy of the user’s password hash and uses it to decrypt the rest of the request. If the decryption is successful, that means the client used the correct password hash and the user has successfully authenticated. Once the user is authenticated, the KDC AS sends the user’s client a  ticket granting ticket   (TGT) . The TGT includes a unique session key and a timestamp that specifies how long that session is valid (normally 8 or 10 hours). Importantly, before sending the TGT, the KDC encrypts it using the password hash for a special account, the  KRBTGT account. ...
4 comments
Read more

Checkpoint - Exporting Objects in CSV format

Be it a Network Operations Manager, Security Architect or a Security Auditor, the people up the hierarchy always harangue the Security Engineers to compile the list of firewall objects or rules or policies or the traffic statistics and so on.. This can turn out to be quite hectic especially if there are no built in features to systematically provide the output in a "layman-readable" format. Come, Checkpoint's "Object Explorer..."  which not only provides the output in the "layman-readable" format, but also provides in-built filtering mechanisms, thereby ensuring that the Security Engineer doesn't have to rely on Google for building his scarce Microsoft Excel data filtering skills. The following screenshots will show how easy it is, with Checkpoint R80.10 to generate the firewall configuration inventory. On the SmartConsole Unified Portal, navigate to Menu >> Open Object Explorer... Select the Categories you wish to see in your output: Click o...
Post a Comment
Read more

MITRE ATT&CK - Understanding Kerberos (for Golden Ticket Attack)

Kerberos = Network Authentication Protocol used by AD environments Provides authentication by issuing tickets to authenticate users and allow them access to the services Tickets are distibuted by KDC (Key Distribution Center), which is typically a Domain Controller (DC) During initial authentication, a TGT (Ticket Granting Ticket) is a ticket asigned to a user by KDC. TGT is later used to authenticate the user to the KDC in order to request a service ticket from TGS (Ticket Granting Service). Service tickets are granted for authentication against services. List of steps / negotiations for Kerberos authentication (of the user with the service): The user requests  (AS-REQ)  a TGT from the KDC and the KDC verifies and validates the credentials and user information. This request if often done automatically at login. After authenticating the user, the KDC sends an encrypted TGT back to the requester  (AS-REP) . The user presents the TGT to the DC and requests a TGS  (TGS-...
Post a Comment
Read more