vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For example, a proxy routing table can be attached to subnet 10.10.3.0/24 and directs all public flows to the NFV proxy.





 Functions used in an Edge proxy firewall 

This use case uses the following functions of Edge proxy firewalls:



* Disabling the IP spoofing check on 10.10.0.5 and 10.10.1.5 interfaces to enable source address preservation. This action requires elevated IAM permissions on the instance.
* A public gateway for outbound flows with resources that are not directed through the NFV proxy.
* The floating IP attached to the 10.10.0.5 interface to enable inbound and outbound public flows directly to the NFV proxy.
* Adding stateful security groups and network access control lists (ACLs) to the instances interfaces and VPC subnets, respectively, to provide additional isolation resources within the VPC.









 Use case 2: Public load balancer 

Zoom

![Public load balancer use case](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc//images/cr_use_case_2.png)

Figure 2. Public load balancer use case



Table 2. Public load balancer Web egress routing table

 Destination Action Next hop Location 

 10.10.0.0/16 Delegate Dallas DC 1 
 10.11.0.0/16 Delegate Dallas DC 1 
 166.26.0.0/16 * Delegate Dallas DC 1 
 166.8.0.0/14 * Delegate Dallas DC 1 
 0.0.0.0/0 Deliver 10.10.1.5 Dallas DC 1 





 Objective: public load balancer 

Hosting web applications using a client-defined application or network load balancer.

Utilizing VPC custom routes with per-subnet egress routing, you can create a table to override the system-implicit routing with the VPC network without updating routing information on each instance. In this example, the source IP from the internet users to the web layer is preserved.
Network Access Control Lists (ACLs) are used to manage allow and deny rules on a subnet level. ACLs are used to manage network traffic between subnets, too. The default ACL for a subnet opens the subnet for all traffic. If you wanted more strict security measures, you would need to add rules to the ACL. When you add rules, keep in mind that required services like DNS or OS patch and packages downloads might be affected by those rules. For more information, see [Security in your VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-security-in-your-vpc).





 Security Groups 

A Security Group is a set of allow-only firewall rules. You can apply these rules to one or more bare metal servers or VSIs. You can also create a default Security Group with Secure Shell (SSH) and ICMP (ping) during VPC creation, which allows ICMP and SSH from any IP address. These rules need to restrict the IPs or IP ranges from which you are planning to access the VPC.









 Storage 

Block storage is provided with your virtual servers and uses input/output operations per second (IOPS) to determine storage needs. It is ideal for storage-intensive applications with high I/O needs, such as an OS, and database and application software. This option is the perfect companion for SAP HANA workloads.

All Block storage is selected based on capacity (GB) and performance (IOPS) measurements and is required to meet a specific SAP Workload.

IOPS values are measured based on 16 KB block size with a 50-50 read/write mix. To achieve a maximum I/O throughput, it's advisable to look at the tier and custom profiles available for storage and find the optimal combination of size and IOPS.

Storage volumes differ in performance, depending on their IOPS tier. You can select among 3, 5, and 10 IOPS/GB (see [Tiered IOPS profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-profilestiers)). You can also select a [custom s
ALLOW_PING would be applied as an out firewall on the interfaces of DEPARTMENTB zone (dp0bond1.30 and dp0bond1.40). As this is installed by the zone policy, only traffic originating from the source zone's interfaces (dp0bond1.50) would be checked against the ruleset.





 Session and packet logging 

The VRA supports two types of logging:



1. Session logging. Use security firewall session-log command to configure firewall session logging.

For UDP, ICMP, and all non-TCP flows, your session will transition to four states over the lifetime of the flow. For each transition, you can configure the VRA to log a message. TCP has a larger number of state transitions, each of which can be configured to log. The following is an example of setting up session-log for your firewall:

set security firewall session-log icmp established
set security firewall session-log tcp established
set security firewall session-log udp established
2. Per packet logging. Include keyword log in firewall or NAT rule to log every network packet that matches the rule.

Per-packet logging occurs in the packet forwarding paths and generates large amounts of output. It is very important to note that per-packet logging can greatly reduce the throughput of the VRA, cause performance issues, and dramatically increase the disk space used for the log files. We recommend using per packet logging only for debugging purposes. For all operational purposes, stateful session logging should be used instead of per-packet logging.
You can also restrict access to the HTTP port to a subset of addresses, use --remote <IP address or CIDR> in the above command to limit who can access this server, i.e. ibmcloud is security-group-rule-add $SG_ID inbound tcp --remote YOUR_IP_ADDRESS --port-min 80 --port-max 80 --json
6. Add a rule to allow outbound to all, this is required to install software, it can be disabled or removed later on.

ibmcloud is security-group-rule-add $SG_ID outbound all --json







 Create Virtual Server Instance 



1. IBM Cloud periodically updates the Ubuntu image with the latest software, obtain the image ID for latest Ubuntu 20.x by running the following command.

IMAGE_ID=$(ibmcloud is images --json | jq -r '.[] | select (.name=="ibm-ubuntu-22-04-1-minimal-amd64-3") | .id')
2. Create virtual server instance



NIC_ID=$(ibmcloud is instance-create vsi-lamp-1 $VPC_ID $(ibmcloud target --output json | jq -r '.region.name')-1 cx2-2x4 $SUBNET_ID --image-id $IMAGE_ID --key-ids $SSHKEY_ID --security-group-ids $SG_ID --json | jq -r '.primary_network_interface.id')



1. Reserve a Floating IP

FLOATING_IP=$(ibmcloud is floating-ip-reserve fip-lamp-1 --nic-id $NIC_ID --json | jq -r '.address')
2. Connect to the server with SSH, note that it may take a minute for the newly created server to be accessible via SSH.

ssh root@$FLOATING_IP

You will need to know the Floating IP for accessing the virtual server via your browser.
* A context is a combination of network zones and endpoint types.



The contexts that you configure define the boundary for the associated resources.

The necessary resource attributes in context-based restrictions rules are accountId and serviceName. Rules must be scoped to an account and a specific service.

Context-based restriction rules are applied by the following logic:



* Access is granted by a rule only when at least one of the rule's contexts allows access.
* If multiple rules are applicable to a particular resource, access is granted only when all applicable rules allow access.
* If no rules are applicable to a particular resource, access is determined exclusively by IAM policies.



Unlike IAM policies, context-based restrictions don't assign access. Context-based restrictions check that an access request comes from an allowed context that you configure.

The interface that you use to access a resource, such as the console, CLI, or API, doesn't affect how a rule applies to that resource. The rule applies the same way across all interfaces and is based on the client IP address.



 Rule enforcement 

You can decide how you want to enforce a rule upon creation and update the rule enforcement at any time.

Enabled
: Enforce the rule. Depending on the service that you select, monitoring denied access attempts through Activity Tracker might be available. Review each service's documentation to learn about how they integrate with context-based restrictions.

Disabled
: No restrictions apply to your account resources. Select this option if you're not ready to enable the rule.

Report-only
: Depending on the service that you select, you can monitor how a rule affects access without enforcing it. With report-only mode, all attempts to access resources in the account are logged in Activity Tracker. If available, monitoring is recommended for 30 days before you enforce a rule.

Report-only mode is not available for all services, so review each service's documentation to learn about how they integrate with context-based restrictions.

You can monitor the impact of your enabled and report-only rules. For more information, see [Monitoring context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-cbr-monitor).
After you create your zones, you can attach the zones to your network resources by creating rules. When you add resources to a rule, you can choose from the available [types of endpoints](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-whatiscontext-restrictions-endpint-type) that are specific to your network topology.



 Create rules by using the API 

You can define rules with the API by using the information that you collected from creating network zones.

Review the following example to learn how to create rules for Secrets Manager. For more information, see the [API docs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-rule).

The following example payload creates a rule that protects the CLUSTER-ID cluster. Only resources in the NETWORK-ZONE-ID zone can access the cluster. Given that no operations are specified, resources in the NETWORK-ZONE-ID zone can access both the cluster and management APIs.

{
"description": "Example rule 1",
"resources": [
{
"attributes":
{
"name": "accountId",
"value": "ACCOUNT-ID"
},
{
"name": "serviceName",
"value": "secrets-manager"
},
{
"name": "serviceInstance",
"value": "CLUSTER-ID"
}
]
}
],
"contexts": [
{
"attributes":
{
"name": "networkZoneId",
"value": "NETWORK-ZONE-ID"
},
{
"name": "endpointType",
"value": "private"
}
]
}
]
}
rule-f4d30138-01c1-409d-a469-fa99a23f2fbd - Check whether App ID redirect URIs are not using localhost or 127.0.0.1
rule-6e0c618d-523d-4352-a1d1-12bb9905b914 - Check whether App ID redirect URIs are not using wildcards ()
rule-1d2287c7-954e-4425-897b-351c30be723c - Check whether App ID Cloud Directory users aren't able to update their own accounts
rule-9786160b-ee91-45ab-b84b-9806541e0fc6 - Check whether App ID Cloud Directory users aren't able to self-sign up to applications
rule-d9247d0e-dce5-4854-849a-4a9033c8fe8d - Check whether App ID anonymous authentication is disabled
rule-9246d682-f7c5-4aac-8751-3947e4f27b0b - Check whether App ID password strength regex is configured
rule-168f8081-dbd6-4cbc-bf19-f9934b39d59c - Check whether App ID advanced password policies are enabled
rule-dd1600d2-2e69-4ada-bca5-9e70b76ccd21 - Check whether App ID avoid password reuse policy is enabled
rule-5b662adf-fcac-4081-a10d-1aa7109aba4e - Check whether App ID password expiration policy is enabled
rule-59cb7d09-feab-48fc-b18b-ee581ca1761e - Check whether App ID prevent username in password policy is enabled
rule-0b082506-2481-4212-a150-d198357fcc3a - Check whether App ID multifactor authentication (MFA) is enabled for Cloud Directory users
Known limitations of FortiGate Security Appliance 1 Gbps 

There are some limitations to be aware of using your FortiGate Security Appliance (FSA) 1 Gbps.



*  Incompatible with Windows Network Load Balancing (NLB) due to the way ARP is processed.
*  High Availability fail over functionality is not exposed to the user. If the master firewall malfunctions, but does not fail over automatically, a support case is required. Device monitoring for critical services is recommended to ensure that firewalls are passing traffic.
*  A FortiGate Security Appliance cannot be deployed on a VLAN that is associated with a Network Gateway, Hardware Firewall, or another FortiGate Security Appliance.
*  The FortiGate Security Appliance is associated with a single public customer VLAN (the "inside" VLAN) and cannot access the private network.
*  Set Rules Bypass does not work on FSA 1 Gbps. Set Rules Bypass applies to Hardware Firewall (Standard and Dedicated).
* UI
* CLI
* API
* Terraform







 Creating context-based restrictions 

Context-based restrictions allow you to manage user and service access to specific cloud resources. You can define restrictions to the resources based on contexts, such as network zones and endpoint types. For more information, see [What are context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-whatis&interface=ui).

User and account-level IP address restrictions can also affect users' ability to access resources. To view account-level IP address restrictions, go to [Settings](https://cloud.ibm.com/iam/settings). To view individual user settings, go to [Users](https://cloud.ibm.com/iam/users) and view each user's IP address restrictions in the details tab.



 Before you begin 

To set up context-based restrictions, you must be the account owner or have an access policy with the administrator role on all account management services. For more information, see [Assigning access to account management services](https://cloud.ibm.com/docs/account?topic=account-account-services).





 Creating network zones 

By creating network zones, you establish a list of allowed locations where an access request originates. A set of one or more network locations can be specified by IP addresses such as individual addresses, ranges or subnets, and VPC IDs. After you create a network zone, you can add it to a rule.

To create a network zone, complete the following steps.



1. In the IBM Cloud console, click Manage > Context-based restrictions, and select Network zones.
2. Click Create.

Instead of creating a zone by using UI inputs, you can use the JSON code form to directly enter JSON to create a zone by clicking Enter as JSON code.
3. Enter a unique name and a description.
4. Enter the allowed IP addresses where an access request can originate. Include IP address exceptions in the deny list, if necessary.
5. Enter the allowed VPCs.
ibmcloud is network-acl-rule-add $acl_id <allow|deny> <inbound|outbound> <protocol> <source_CIDR> <destination_CIDR> --name <new_rule_name>

For example, say that you want your worker nodes to communicate with a subnet in your organization's network, 207.42.8.0/24. Your worker nodes must be able to both send and receive information from devices or services on this subnet. You can create an outbound rule for traffic to and an inbound rule for traffic from your organization's subnet:

ibmcloud is network-acl-rule-add $acl_id allow outbound all 0.0.0.0/0 207.42.8.0/24 --name corporate-network-outbound
ibmcloud is network-acl-rule-add $acl_id allow inbound all 207.42.8.0/24 0.0.0.0/0 --name corporate-network-inbound
10. Create rules to deny all other egress from and ingress to worker nodes that is not permitted by the previous rules that you created. Because these rules are created last in the chain of rules, they deny an incoming or outgoing connection only if the connection does not match any other rule that is earlier in the rule chain.

ibmcloud is network-acl-rule-add $acl_id deny outbound all 0.0.0.0/0 0.0.0.0/0 --name deny-all-outbound
ibmcloud is network-acl-rule-add $acl_id deny inbound all 0.0.0.0/0 0.0.0.0/0 --name deny-all-inbound
11. Apply this ACL to the subnet. When you apply this ACL, the rules that you defined are immediately applied to the worker nodes on the subnet.

ibmcloud is subnet-update <subnet_ID> --network-acl-id $acl_id

Example output
For more information about ACLs, see [Security in VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-security-in-your-vpc). For more information about ACLs with IBM Cloud bare metal server, see [Introduction to IBM Cloud bare metal server networking](https://cloud.ibm.com/docs/vpc?topic=vpc-bare-metal-servers-network).





 Security groups with VMware workloads 

A security group acts as a virtual firewall that controls the traffic for one or more virtual server network interfaces and IBM Cloud bare metal server PCI or VLAN interfaces. A security group is a collection of rules that specify whether to allow or deny traffic for an associated interface. You can associate an interface with one or more security groups and edit the security group rules.

In this design, you can use security groups to create a logical grouping of management, vSAN, vMotion and TEP traffic types, and apply rules to allow required traffic flows. You can also use security groups as a source or destination in the rules to create more dynamic rules without specifying IP addresses.

When security groups are used with VLAN interfaces in VMware VMs, to avoid misconfigurations and misunderstandings, it is important to understand how traffic flows to and from standard and distributed vSwitches, and inside the hosts.

In a VMware environment, traffic between VLAN network interfaces that have the same VLAN ID on the same bare metal server is typically switched by the standard and distributed vSwitches within the ESXi host. Also, it never reaches the VPC network.

For example, on a vSphere Cluster that consists of multiple bare metal server hosts, and you configured a distributed vSwitch, or the hosts are using the default standard switch. In this case, you can create a port group with VLAN ID 100 and add it to the specific vSwitch or vSwitches. The traffic between vNICs of two VMs that are attached to Port Group 100 is controlled by the vSwitch.

The setting has the following consequences:



* Security Group rules that control traffic between the network interfaces in Port Group VLAN ID 100 are not applied.
Procedure to find the firewall and SNAT rules defined (Entrust CloudControl 5.x and NSX-V only) 



1. Log in to the VMware® vSphere Web Client (FLEX) and find the ESG mgmt-nsx-edge.
2. Click Home > Networking & Security > NSX Edges.
3. Double-click the ESG mgmt-nsx-edge and click the Manage tab.
4. Go to the Firewall tab and find the Entrust rules. Note the source IP addresses, which are the IP addresses for the Entrust VMs.
5. Go to the NAT tab and find the SNAT rules that are created for the Entrust VMs. The source IP addresses match the IP addresses that you noted in the previous step.







 Procedure to enable internet connectivity for Entrust CloudControl (Entrust CloudControl 5.x only) 

The following steps apply for updating the Entrust CloudControl network settings on the primary VM, which is used for the license upgrades. You don't need to update the settings for the secondary VM.



1. Complete steps 1-3 in the previous procedure.
2. Click Settings and then click Interfaces. Note the IP address for the private uplink, which becomes the new default gateway.
3. Go to the Entrust CloudControl service details page, click View Entrust CloudControl Web UI and log in with the credentials from the service details page.
4. Note the existing default gateway. Click Configuration > Network. Note the gateway IP address that is listed, which becomes the gateway for the static route.
5. Add a static route. Click Configuration > Static Routes. Click Add, enter the following information, and click OK.

Network Address: 10.0.0.0
Mask: 255.0.0.0
Gateway: IP noted in step 4
Device: Network 1
6. Change the default gateway. Click Configuration > Network and replace the IP address in the Gateway field with the one you noted in Step 3 and click Save.
ibmcloud is network-acl-rule-add $acl_id deny inbound all 0.0.0.0/0 0.0.0.0/0 --name deny-all-inbound
11. Apply this ACL to the subnet. When you apply this ACL, the rules that you defined are immediately applied to the worker nodes on the subnet.

ibmcloud is subnet-update <subnet_ID> --network-acl-id $acl_id

Example output

ID a1b2c3d4-f560-471b-b6ce-20067ac93439
Name mysubnet1
IPv* ipv4
IPv4 CIDR 10.240.0.0/24
IPv6 CIDR -
Address Available 244
Address Total 256
ACL mycluster-mysubnet1-acl(b664769d-514c-407f-a9f3-d44d72706121)
Gateway pgw-18a3ebb0-b539-11e9-9838-f3f4efa02374(f8b95e43-a408-4dc8-a489-ed649fc4cfec)
Created 2019-08-02T10:20:17-05:00
Status available
Zone us-south-1
VPC myvpc(ff537d43-a5a4-4b65-9627-17eddfa5237b)
12. Repeat steps 2 - 11 for each subnet that you found in step 1.



ACL rules are applied to traffic in a specific order. If you want to add a rule after you complete these steps, ensure that you add the rule before the deny-all-inbound or deny-all-outbound rule. If you add a rule after these rules, your rule is ignored, because the packet matches the deny-all-inbound and deny-all-outbound rules and is blocked and removed before it can reach your rule.
Apply simple masking on clear data 

This section describes a simple RBAC policy to apply basic data masking for all users. Follow the steps below to apply masking on the data using Data Security Broker Manager.

Step 1: RBAC configuration:

Configure RBAC for all connections to Shield, by setting the Mode as Required. Also, set the User Determination as Session, to reference the DB session user ID for User Group membership. However, when configuring a global RBAC policy, the User Determination is not relevant.

Step 2: User group - All-Users:

You can create a Global user group called "All-Users". Select the Global checkbox and do not specify any Allowed Subnets. (0.0.0.0/0 is automatically filled when this text box is left blank.) This User Group applies to all possible connections to Shield.

Step 3: RBAC policy - Default Masking:

You can create two Masking policies which are nearly identical. The only difference is that one policy applies for VARCHAR columns, and the other applies for INT columns. The parameters are as follows:

The first policy, "Default Varchar Masking", has one Rule to use MASK_VARCHAR for the All-Users user group. The second policy, "Default Int Masking", has one Rule to use MASK_INT for the All-Users user group.

Because both rules contain the global All-Users group, the default permission is irrelevant in this case.

Step 4: Application of Masking policies on data columns:

Finally, select a number of columns to mask. For each column, remove the DEFAULT_CTR_DET selection and add one or the other RBAC policy based on the Data Type.

On the Confirmation page, review the data protection schema. Because there is no Encryption defined, and no data transformation taking place, the option for Deploy & Migrate is unavailable.

Deploy the policy. If you connect to the Shield proxy, you can see that the Data Masking has been applied to the selected columns.