vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Firewall access - allowed IP addresses 

Access to Schematics using IAM allowed IP addresses has been replaced with [context based restrictions](https://cloud.ibm.com/docs/schematics?topic=schematics-access-control-cbr).

Performing post-configuration of deployed resources using Terraform and Ansible requires IP network access to the resources private cloud network zones. Typically these private networks will be protected using a firewall or VPC access control policies. To allow the Schematics hosted instances of Terraform and Ansible to access these zones, firewall or VPC access policies must be configured to permit access to the Schematics originating IP addresses.

Typically post-configuration is performed via SSH as illustrated with [Schematics Actions](https://cloud.ibm.com/docs/schematics?topic=schematics-sc-actions) performing configuration operations over SSH using Ansible. With Ansible a bastion host must be configured to enable secure SSH access. Refer to the [Schematics Actions](https://cloud.ibm.com/docs/schematics?topic=schematics-sc-actionssc-actions-overview) documentation for details of the required VPC network configuration and bastion host setup.



 Schematics IP addresses 

The following tables document the public IP addresses used by Schematics that must be allowed access to private network resources to perform post-configuration.

At run time Schematics dynamically selects a worker node and region to execute the job. The job may run on any of the defined IP addresses within a geography. For instance in the US using any of the us-south and us-east IP addresses, or for Europe using any of the eu-gb or eu-de addresses.



Region and supported public and private IPs

 Region Zone Public IP addresses Private IP addresses
Subnets for webhook notifications from IBM Cloud Security and Compliance Center Workload Protection 

To receive alert notifications by using webhooks from the IBM Cloud Security and Compliance Center Workload Protection service, you may need to define firewall rules for the subnets that are invoking your webhooks.



Table 6. Source Subnets for Webhook notifications from IBM Cloud Security and Compliance Center Workload Protection

 Region Alert Notification Source Subnets 

 US-SOUTH 150.239.180.0/25 <br>169.46.0.64/29 <br>169.46.39.48/28 <br>169.46.58.24/29 <br>169.47.115.192/28 <br>169.47.71.24/29 <br>169.48.214.64/29 <br>169.48.235.16/28 <br>169.60.151.168/29 <br>169.62.221.32/28 <br>174.36.68.96/27 <br>50.22.148.64/26 <br>52.116.222.192/27 <br>52.117.187.192/27 <br>52.118.158.0/25 <br>52.118.7.64/26 <br>67.228.207.64/26 <br>67.228.219.0/25 
 EU-DE 149.81.151.128/27 <br>149.81.201.192/26 <br>149.81.77.72/29 <br>149.81.99.192/28 <br>158.177.44.192/26 <br>159.122.102.32/29 <br>161.156.1.224/27 <br>161.156.102.200/29 <br>161.156.69.144/28 <br>161.156.77.64/26 <br>169.50.36.64/27 <br>169.50.9.0/28
In the Triggered Exclusion Rules section click Add daily rule.
2. Drag the slider to the percentage of the daily usage quota when you want the rule triggered. For example, 50%. If you try to set a percentage where an exclusion rule exists, you will be warned that the existing rule will be replaced.
3. Select the source of the logs you want to exclude.
4. Select the apps you want to exclude.
5. Specify a [query](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-views) to select the log lines you want to exclude.
6. Select if your want to discard all matching log lines until midnight UTC and if you want those log lines preserved for live tail and alerting.

All configured alert recipients will be alerted when the percentage threshold of the daily quota is reached. This behavior cannot be changed.
7. Click Apply to save the exclusion rule.

Check the query in a custom view by entering the search criteria in the search bar of the Everything view, and validating that the data that is displayed is the data that you want excluded.







 Monthly exclusion rules 

To specify a monthly exclusion rule, do the following from the Usage Quotas dialog:

Verify that each exclusion rule that you add behaves as expected. Improper configured exclusion rules can result in storing data not intended for storage.



1. In the Triggered Exclusion Rules section click Add monthly rule.
2. Drag the slider to the percentage of the monthly usage quota when you want the rule triggered. For example, 50%. If you try to set a percentage where an exclusion rule exists, you will be warned that the existing rule will be replaced.
3. Select the source of the logs you want to exclude.
4. Select the apps you want to exclude.
5. Specify a [query](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-views) to select the log lines you want to exclude.
6.
Allow TCP IP or CIDR CIDR block of the subnet your workload or application is located (for example, 10.60.0.0/18) 443 IP or CIDR IP address of F5 workload interface (for example, 10.5.50.5) Any 
 Deny ALL Any Any Any 









 F5 bastion interface 



 Security group 

Security group outbound rules



F5 bastion interface: Security group outbound rules
This table shows the security group rules that are needed for the F5 bastion interface.

 Protocol Destination type Destination Port 

 TCP CIDR block CIDR Block value from Bastion subnet (for example, 10.5.70.0/24) Ports 3023-3025 
 TCP CIDR block CIDR Block value from Bastion subnet (for example, 10.5.70.0/24) Ports 3080-3080 







 Access control list 

ACL inbound rules

ACL outbound rules



F5 Bastion interface: access control list inbound rules
This table shows the inbound access control list rules that are needed for the F5 bastion interface.

 Allow or Deny Protocol Source type Source Value Source Port Destination type Destination Value Destination Port 

 Allow TCP IP or CIDR CIDR Block value from Bastion subnet (for example, 10.5.70.0/24) 3023-3025 IP or CIDR IP address of F5 bastion interface (for example, 10.5.60.5) Any 
 Allow TCP IP or CIDR CIDR Block value from Bastion subnet (for example, 10.5.70.0/24) 3080-3080 IP or CIDR IP address of F5 bastion interface (for example, 10.5.60.5) Any 
 Deny ALL Any Any Any 











 Next steps 



* [Set up a full tunnel client-to-site VPN with BIG-IP](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-connectivity-f5-tutorial)
WAF actions and rule sets 



 WAF actions 

The following table shows the actions that Web Application Firewalls (WAFs) can take.



Table 1. WAF actions

 Action Definition 

 Block Blocking an attack stops any action before it is posted to your website. 
 Simulate To test for false positives, set the WAF to Simulate mode, which records the response to possible attacks without challenging or blocking. 
 Challenge A challenge page asks visitors to submit a CAPTCHA to continue to your website. 
 Threshold (or sensitivity setting) Set rules to trigger more or less, depending on sensitivity. 



In Enterprise plans, you have the flexibility to turn on or off individual WAF rules for a particular URI in a domain, instead of the whole domain or subdomain. For more information, see the [waf-override-create](https://cloud.ibm.com/docs/cis-cli-plugin?topic=cis-cli-plugin-cis-clicreate-waf-override) command.





 CIS rule sets 

Select View CIS Rules to reveal the rule sets of this package. Rule sets are as follows:



* Drupal - Enable this rule set only if the Drupal CMS is used for this domain.
* Flash[1] - Enable this rule set only if Adobe Flash content is used for this domain.
* Joomla[2] - Enable this rule set only if the Joomla CMS is used for this domain.
* Magento[3] - Enable this rule set only if the Magento CMS is used for this domain.
* Miscellaneous - Contains rules to deal with known malicious traffic, or patch flaws in specific web applications.
* PHP[4] - Enable this rule set if PHP is used for this domain.
* Plone[5] - Enable this rule set only if the Plone CMS is used for this domain.
* Specials - Contains a number of rules that were created to deal with specific attack types.
* WHMCS[6] - Enable this rule set only if WHMCS is used for this domain.
* Wordpress - Enable this rule set only if the WordPress CMS is used for this domain.
* To edit a rule, click the Actions menu ![Actions menu](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc/images/overflow.png), click Edit, make your changes, then click Save.
* To delete a rule, click the Actions menu ![Actions menu](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc/images/overflow.png), click Delete, then click Delete again.
* To create a rule, click the Create button.



For each rule, specify the following information:



* Select the protocols and ports to which the rule applies.
* Specify a CIDR block or IP address for the permitted traffic. Alternatively, you can specify a security group in the same VPC to allow traffic to or from all instances that are attached to the selected security group.



Tips:



* All rules are evaluated, regardless of the order in which they're added.
* Rules are stateful, which means that return traffic in response to allowed traffic is automatically permitted. For example, you created a rule that allows inbound TCP traffic on port 80. That rule also allows replying outbound TCP traffic on port 80 back to the originating host, without the need for another rule.
* For Windows images, make sure that the security group that is associated with the instance allows inbound and outbound Remote Desktop Protocol traffic (TCP port 3389).



7. Optional: To view interfaces that are attached to the security group, click the Attached resources tab and review the Attached interfaces section.
8. When you finish creating rules, click the Security groups breadcrumb at the top of the page to return to your list of Security groups for VPC.







 Updating the default security group from the CLI 

Complete the following steps to update the default security group by using the CLI:



1.
: DNS Domain ID. For ua-rules and lockdowns type rule, it is a required parameter.

--page
: Page number of paginated results. The default value is 0.

--per-page
: Maximum number of access rules per page. The minimum value is 5. The default value is 20.

-i, --instance
: Instance name or ID. If not set, the context instance specified by ibmcloud cis instance-set INSTANCE is used.

--output
: Specify output format, only JSON is supported.





 Examples 

List firewall rules.

ibmcloud cis firewalls -t access-rules -i "cis-demo"
ibmcloud cis firewalls -t ua-rules -d 31984fea73a15b45779fa0df4ef62f9b -i "cis-demo"
ibmcloud cis firewalls -t lockdown -d 31984fea73a15b45779fa0df4ef62f9b -i "cis-demo"







 ibmcloud cis firewall 

Get details of a firewall rule.

ibmcloud cis firewall FIREWALL_RULE_ID (-t, --type Type) [-d, --domain DNS_DOMAIN_ID] [-i, --instance INSTANCE] [--output FORMAT]



 Command options 

FIREWALL_RULE_ID
: The ID of firewall rule. Required.

-t, --type
: Type of firewall rule to create. Valid values: access-rules, ua-rules, lockdowns.



* access-rules: Access Rules are a way to allow, challenge, or block requests to your website. You can apply access rules to one domain only or all domains in the same service instance.
* ua-rules: Perform access control when matching the exact UserAgent reported by the client. The access control mechanisms can be defined within a rule to help manage traffic from particular clients. This enables you to customize the access to your site.
Using page rules with caching 

Page rules give you the ability to take various actions based on the page's URL, such as creating redirects, fine-tuning caching behavior, or enabling and disabling services.

A page rule takes effect on a given URL pattern that matches the following format:

<scheme>://<hostname><:port>/<path>

For example:

https://www.example.com:80/image.png

The scheme and port components are optional. If the scheme component is omitted, the format accepts http:// and https:// protocols. If the port is not specified, the rule matches all ports. You can perform basic wildcard matches by using a * symbol in your rule pattern, allowing it to match a series of similar patterns.



 Page rule considerations 



* Only one page rule takes effect on any given request.
* Page rules are given priority in an order from top to bottom. After a URL matches a rule, only that rule is applied; that is, if a page rule has triggered already on a request, any subsequent rules that also match the URL pattern do not take effect.
* As a general rule, it is recommended to order from most-specific to least-specific rules.
* Page rules can be disabled, in which case they take no action. However, you can still see the rules in the list and edit them. Setting the Enabled toggle to Off creates a page rule that is disabled initially.







 Forwarding (URL redirection) 

Redirect one URL to another using an HTTP 301 or 302 redirect. The contents of any section of a URL that a wildcard matches can be referenced using $X syntax. The X indicates the index of a glob in the pattern: $1 is replaced with the first wildcard match, $2 with the second wildcard match, and so on.

For example, suppose you set the following rule where:



* URL match = .example.com/
* Enabled = On
* Setting = Forwarding URL
* Set as = 301 Permanent Redirect to http://example.com/$2/
Canceling a Hardware Firewall 

Your Hardware Firewall can be cancelled at any time, by following the instructions here.



1.  From your browser, open the [IBM Cloud catalog](https://cloud.ibm.com) and log into your account.
2.  Select the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) from the top left, then click Classic Infrastructure.
3.  Select Devices > Device List and click on the firewall protected device you want to cancel.
4.  In the Add-ons section, click the Firewall details button. It will redirect you to the Firewall Details page.
5.  In the Firewall Details page, click the Actions dropdown menu and choose Cancel firewall. In the next dialog, choose whether you want to cancel immediately or at the next billing cycle.



This will leave all devices on the VLAN without front end firewall protections. This service is provided month to month and billing will be discontinued for the next month upon cancellation.
Managing access with context-based restrictions 

After you set up your App Configuration service instance, you can manage access by using [context-based restrictions (CBR)](https://cloud.ibm.com/context-based-restrictions/overview).



 Managing CBR settings 

With [context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-whatis), you can define and enforce user and service access restrictions to App Configuration resources based on specified criteria. These resources include Internet Protocol (IP) addresses that are linked to your App Configuration instance.

To restrict access, you must be the account owner or have an access policy with the administrator role on all account management services.





 Overview 

To restrict access, you must create [zones](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-create&interface=uinetwork-zones-create) and [rules](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-create&interface=uicontext-restrictions-create-rules).

First, create a zone with the appropriate details for network or resource definitions. Then, attach that zone to the specified resource to restrict access. You can create zones and rules by using a ReSTful [API](https://cloud.ibm.com/apidocs/context-based-restrictionsintroduction) or with [context-based restrictions](https://cloud.ibm.com/context-based-restrictions/overview). After you create or update a zone or a rule, it might take a few minutes for the change to take effect.

CBR rules do not apply to provisioning or deprovision processes.





 Understanding network zones 

By creating network zones, you can define an allowlist of network locations where access requests originate, to determine when a rule can be applied. The list of network locations can be specified by using IP addresses, such as individual addresses, ranges or subnets, and Virtual Private Cloud (VPC) IDs.

After you create a network zone, you can add it to a rule.



 Creating network zones by using the CBR API
Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Flow control restrictions include, for example, keeping export-controlled information from being transmitted in the clear to the Internet, blocking outside traffic that claims to be from within the organization, restricting web requests to the Internet that are not from the internal web proxy server, and limiting information transfers between organizations based on data structures and content. Transferring information between information systems representing different security domains with different security policies introduces risk that such transfers violate one or more domain security policies. In such situations, information owners/stewards provide guidance at designated policy enforcement points between interconnected systems. Organizations consider mandating specific architectural solutions when required to enforce specific security policies. Enforcement includes, for example: (i) prohibiting information transfers between interconnected systems (i.e., allowing access only); (ii) employing hardware mechanisms to enforce one-way information flows; and (iii) implementing trustworthy regrading mechanisms to reassign security attributes and security labels. Organizations commonly employ information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations (e.g., networks, individuals, and devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Enforcement occurs, for example, in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, firewalls) that employ rule sets or establish configuration settings that restrict information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Organizations also consider the trustworthiness of filtering/inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Control enhancements 3 through 22 primarily address cross-domain solution needs which focus on more advanced filtering techniques, in-depth analysis, and stronger flow enforcement mechanisms implemented in cross-domain products, for example, high-assurance guards. Such capabilities are generally not available in commercial off-the-shelf information technology products.
Security groups guidelines 

Consider the following guidelines when working with IBM™ Cloud Security Groups.



 Rules 



* Each security group defines different sets of network rules that define the incoming and outgoing traffic for a virtual server instance. You can specify rules for both IPv4 and IPv6.
* When a new security group is created by using the IBM Cloud console, the default behavior is to create a single rule that allows all outbound traffic from the virtual server instance. You must clear the "Create group with a default rule to allow all outbound traffic" check box to create the security group with no rules. A security group with no rules blocks all traffic (both inbound and outbound).
* To allow inbound traffic, outbound traffic, or both, you must add at least one security group that includes security group rules that allow traffic.
* Security group rules only can be permissive. Traffic is blocked by default.
* Users with the Manage Security Groups privilege can add, edit, or delete rules in a security group.
* Changes to security group rules are automatically applied and can be modified at any time.
* The order of rules within a security group does not matter. The priority always falls to the least restrictive rule.
* Rules are stateful. Connections established prior to a security group change are not altered. New connections abide by rules that exist at the time connectivity is established.
* Security groups do not override operating system firewalls on the virtual server. Even if a more restrictive firewall exists on the operating system than what is applied by the security group, the operating system rules will still be enforced.
* If your virtual server needs access to internal services, such as an update server, network attached storage (NAS), or advanced monitoring, ensure that the security group rules accommodate traffic for those internal services. For more information, see [IBM Cloud IP ranges](https://cloud.ibm.com/docs/hardware-firewall-dedicated?topic=hardware-firewall-dedicated-ibm-cloud-ip-ranges).







 Interfaces 



* A security group can be applied to a private network, a public network, or both network interface types.
By using GET /v1/rules with the endpoints that you chose, you can view a list of current rules. Use POST /v1/rules to create new rules. For more information, including a request body example, see [Creating rules by using the API](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-create&interface=apicontext-restrictions-create-rules-api).

After you create rules, you can [update](https://cloud.ibm.com/apidocs/context-based-restrictionsreplace-rule) and [delete](https://cloud.ibm.com/apidocs/context-based-restrictionsdelete-rule) them.





 Creating network rules by using the CBR UI 

After you set the prerequisites and requirements, you can create zones in the UI. For more information about the steps to follow, see [Creating context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-create&interface=uinetwork-zones-create).

You can use the CBR UI to [add resources and contexts](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-create&interface=uicontext-restrictions-create-rules) to your network rules. Keep in mind the limitations.

For example, when you create context-based restrictions for the IAM Access Groups service, users who don't satisfy the rule can't view any groups in the account, including the public access group.

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. Also, the rules might not take effect immediately due to synchronization and resource availability.

After you create rules, you can [update](https://cloud.ibm.com/apidocs/context-based-restrictionsreplace-rule) and [delete](https://cloud.ibm.com/apidocs/context-based-restrictionsdelete-rule) them.







 Next steps