vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* A new T1 named Isolated-NW-T1 and links it to the workload T0. Isolated-NW-T1 is configured to advertise only all NAT IP addresses. This action stops the advertisement of connected segments and advertises only the NAT IP addresses of the segments.
* The following distributed firewall groups.



* Name Cyber-Tools-Segments, Category Segments, Members Cybertools
* Name Cyber-Isolated-Segments, Criteria Segment Tag Equals Isolated-Segments, Scope Cyber



* A distributed firewall policy that is named Cyber-Isolated, which contains the following rules to satisfy their isolation requirements:





Table 1. NSX-T distributed firewall rules

 Rule Name Sources Destinations Services Action 

 Allow access to Isolated Cyber-Tools-Segments Cyber-Isolated-Segments All Allow 
 Allow access between Isolated Cyber-Isolated-Segments Cyber-Isolated-Segments All Allow 
 Deny access to Isolated Any Cyber-Isolated-Segments All Deny 
 Deny access from Isolated Any Cyber-Isolated-Segments All Deny 



When a sandbox is required, the customer uses their preferred scripting tool to automatically:



* Create logical segments connected to Isolated-NW-T1 by using the IP address of the default gateway of that network on the T1. In the following diagram, you can see two Isolated-NW2 and Isolated-NW3 segments with subnets that match NW2 and NW3. These segments are created with Tags and Scopes, such as Scope Cyber and Tag Isolated-Segments. These tags and scope are used in the distributed firewall groups and rules that are listed in the previous table.
* Create destination NAT rules that map destination subnets to translated subnets for IP packets with a source address from the cybertools segment. For example, Src=172.16.67.2->Dst=172.16.68.2 => Src=172.16.67.2->Dst=172.16.253.2.



The required traffic flow is shown in the following diagram where:



* Green designates allowed traffic flow.
* Red designates denied traffic flow.



Zoom

!
ibmcloud cis firewall 4af47b1518be478aa2c8f024af1c0bad -t ua-rules -d 31984fea73a15b45779fa0df4ef62f9b -i "cis-demo"
ibmcloud cis firewall e6106d7ec58e47ebb2fa053dedcd7dcb -t lockdown -d 31984fea73a15b45779fa0df4ef62f9b -i "cis-demo"







 ibmcloud cis firewall-delete 

Delete a firewall rule by ID.

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



 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. Required.



* 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.
* lockdowns: Lock access to URLs in this domain to only permitted addresses or address ranges.



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

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





 Examples 

Delete a firewall rule.
Configuring rate limiting 

Rate limiting (Enterprise plan only) protects against denial-of-service attacks, brute-force login attempts, and other types of abusive behavior targeting the application layer.

Select the type of rate limiting rule, either a Custom rule or Protect login



 Creating a custom rate limiting rule 

Enter a rule name that helps you remember what the rule does. This is an optional field.

In the Traffic matching criteria section, enter the following information.



1. Select the criteria type.
2. Enter the URL that you are rate limiting.
3. Select the number of requests to allow before triggering rate limiting.
4. Select the time period (in seconds) over which the requests can occur before triggering rate limiting. Range is from 10 to 86,400 seconds.



The Advanced Criteria option allows you to specify which HTTP methods, header responses, and origin response codes to further restrict the matching criteria.

Select a value form the Method list menu (ANY is the default).

Update HTTP response header. You can also Add response header to include headers returned by your origin web server.

If you have more than one header under HTTP response header, an AND boolean logic applies. To exclude a header from being matched, use the Not Equal option. Also, each header must be an exact match. However, case sensitivity doesn't apply.

Under Origin response code, type the valid numerical value of each HTTP response code to match. To include two or more response codes, separate each value with a comma. For example, you can enter 401, 403 if you only want those two error codes to count.



 Configuring the response 

Select from the actions listed, and specify the timeout period. In this case, the timeout refers to the ban period that the action takes place. A 60 second timeout means the action is applied for 60 seconds.



Table 1. Actions for rate limiting

 Action Description 

 Block Issues a 429 error when the threshold is exceeded 
 Challenge User must pass a Google reCaptcha Challenge before proceeding. If successful, we accept the request. Otherwise, the request gets blocked.
Prioritizing options 

By default, the action you specify in a rule determines the evaluation sequence for your entire ruleset. However, you can set a priority option that allows you to force the evaluation sequence to occur before triggering a rule.

You can manage a priority using the firewall rules UI in the CIS dashboard. Priority management is also available from the firewall rules API.

The firewall rules engine processes rules in parallel. If you do not specify priority in a large ruleset, a matching conflict is possible. To avoid any conflicts, it is recommended that you explicitly control the evaluation sequence of your ruleset using a priority.

Firewall rules do not have default priorities and do not force you to have a priority for every rule. This gives you the freedom to organize your ruleset the way you want. The numbering can be relatively arbitrary, as long as it makes sense for your particular situation. However, keep in mind the following issues:



*  The evaluation sequence starts from the lowest priority number to the highest.
*  The valid priority range is 1 to 2147483647.
*  Avoid using the number 1 as a priority. Since no other rule can go above it, it makes it harder to renumber your rules.
*  Rules with no priorities are evaluated last.



It is recommended that you group ranges of priority numbers into meaningful categories. For example:



*  5000-9999 - Trusted IP addresses
*  10000-19999 - Blocking rules for bad crawlers
*  20000-29999 - Blocking rules for abusive/spam users



These example priority numbers are valid since you can have many more rules than the limit associated with your domain plan. That limit applies solely to active rules.
ibmcloud cis firewall-update e6106d7ec58e47ebb2fa053dedcd7dcb -t lockdowns -d 31984fea73a15b45779fa0df4ef62f9b --json '{"urls": ["api.mysite.com/some/endpoint"], "configurations": [{"target": "ip", "value": "127.0.0.1"}, {"target": "ip_range", "value": "2.2.2.0/24"}]}' -i "cis-demo"







 ibmcloud cis firewalls 

List firewall rules.

ibmcloud cis firewalls (-t, --type Type) [-d, --domain DNS_DOMAIN_ID] [--page PAGE] [--per-page PER_PAGE ] [-i, --instance INSTANCE] [--output FORMAT]



 Command options 

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



* 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.
* lockdowns: Lock access to URLs in this domain to only permitted addresses or address ranges.



-d, --domain
: 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.
By default, all traffic is allowed.

Each subnet can be attached to only one ACL. However, each ACL can be attached to multiple subnets.

To configure the ACL:



1. In the navigation pane, click Network > Subnets.
2. Click the subnet that you created.
3. In the Subnet details area, click the name of the ACL.
4. Click Add rule to configure inbound and outbound rules that define what traffic is allowed in or out of the subnet. For each rule, specify the following information:



* Select whether to allow or deny the specified traffic.
* Select the protocol to which the rule applies.
* For the source and destination of the rule, specify the IP range and ports for which the rule applies. For example, if you want all inbound traffic to be allowed to the IP range 192.168.0.0/24 in your subnet, specify Any as the source and 192.168.0.0/24 as the destination. But if you want to allow inbound traffic only from 169.168.0.0/24 to your entire subnet, specify 169.168.0.0/24 as the source and Any as the destination for the rule.
* Specify the rule's priority. Rules with lower numbers are evaluated first and override rules with higher numbers. For example, if a rule with priority 2 allows HTTP traffic and a rule with priority 5 denies all traffic, HTTP traffic is still allowed.



See [Configuring rules](https://cloud.ibm.com/docs/vpc?topic=vpc-acl-create-uiexample-configuring-rules) for an example.
5. When you finish creating rules, click the Access control lists breadcrumb at the beginning of the page.



For more information, see [About access control lists](https://cloud.ibm.com/docs/vpc?topic=vpc-using-acls).





 Step 3: Creating a virtual server instance 

To create a virtual server instance in the newly created subnet, use these steps:



1.
internet-svcs.filters.update Update filters. 
 internet-svcs.filters.delete Delete filters. 
 internet-svcs.filters-validate-expr.create Validate a filter expression. 
 internet-svcs.firewall-rules.create Create filter based firewall rule. 
 internet-svcs.firewall-rules.update Update filter based firewall rule. 
 internet-svcs.firewall-rules.delete Delete filter based firewall rule. 
 internet-svcs.ua-rules.create Create user agent blocking rule. 
 internet-svcs.ua-rules.update Update user agent blocking rule. 
 internet-svcs.ua-rules.delete Delete user agent blocking rule. 
 internet-svcs.domain-lockdown-rules.create Create domain lockdown rule. 
 internet-svcs.domain-lockdown-rules.update Update domain lockdown rule. 
 internet-svcs.domain-lockdown-rules.delete Delete domain lockdown rule. 







 List of events: Rate limiting 

The following table lists the actions that are related to rate limiting and generate an event:



Table 7. Actions that generate rate limiting events

 Action Description 

 internet-svcs.rate-limits.create Create rate limiting rule. 
 internet-svcs.rate-limits.update Update rate limiting rule. 
 internet-svcs.rate-limits.delete Delete rate limiting rule. 







 List of events: Routing 

The following table lists the actions that are related to routing and generate an event:



Table 8. Actions that generate routing events

 Action Description 

 internet-svcs.smart-routing.update Enable or disable smart routing. 
 internet-svcs.tiered-caching.update Enable or disable tiered caching. 







 List of events: Certificate packs 

The following table lists the actions that are related to certificate packs and generate an event:



Table 9. Actions that generate certificate pack events

 Action Description 

 internet-svcs.certificate-packs.create Order a dedicated wildcard or custom certificate. 
 internet-svcs.certificate-packs.delete Delete a dedicated wildcard or custom certificate. 







 List of events: Custom certificates
set security firewall name TO_INTERNET rule 10 source address '150.1.2.3'
set security firewall name TO_INTERNET rule 10 state 'enable'
set security firewall name TO_INTERNET rule 20 action accept
set security firewall name TO_INTERNET rule 20 description 'Accept VRA traffic to Internet'
set security firewall name TO_INTERNET rule 20 source address '150.1.2.5'
set security firewall name TO_INTERNET rule 20 state 'enable'

The combination of Source NAT and firewall achieves the required design goal.

Ensure that the rules are appropriate for your design, and that no other rules allow traffic that should be blocked.
* How do I protect the VRA itself with a zone-based firewall?

The VRA does not have a local zone. You can use the Control Plane Policing (CPP) functionality instead as it is applied as a local firewall on loopback.

This is a stateless firewall and you must explicitly allow the returning traffic of outbound sessions that originate on the VRA itself.
* How do I restrict SSH and block connections that come from the internet?

It is considered a best practice to not allow SSH connections from the internet, and to use another means of accessing the private address, such as SSL VPN.

By default, the VRA accepts SSH on all interfaces. To listen only for SSH connections on the private interface, you must set the following configuration:

set service ssh listen-address '10.1.2.3'

Keep in mind that you must replace the IP address with the address that belongs to the VRA.



Platform Building infrastructure



* What is the RMM server?

RackWare Management Module (RMM) server is a software appliance that is offered by RackWare that replatforms your server from a VMware (on-premises or classic) to an IBM Cloud VPC virtual server instance.
* Where can I find more information about the RMM server?

For RMM server overview information, see [RackWare's Cloud Migration](https://www.rackwareinc.com/cloud-migration) documentation.
Get WAF rules GET /v1/{crn}/zones/{domain_id}/firewall/waf/packages/{package_id}/rules internet-svcs.security.read internet-svcs.waf-rules.read 
 Change the action mode of a WAF rule PATCH /v1/{crn}/zones/{domain_id}/firewall/waf/packages/{package_id}/rules/{rule_id} internet-svcs.security.update internet-svcs.waf-rules.update 







 IP Firewall 



Table 7. IP Firewall

 Action Method IAM ACTION AT ACTION 

 Get IP firewall rules GET /v1/{crn}/zones/{domain_id}/firewall/access_rules/rules internet-svcs.security.read internet-svcs.ip-firewall-rules.read 
 Create an IP firewall rule POST /v1/{crn}/zones/{domain_id}/firewall/access_rules/rules internet-svcs.security.manage internet-svcs.ip-firewall-rules.create 
 Update an IP firewall rule PATCH /v1/{crn}/zones/{domain_id}/firewall/access_rules/rules/{rule_id} internet-svcs.security.update internet-svcs.ip-firewall-rules.update 
 Delete an IP firewall rule DELETE /v1/{crn}/zones/{domain_id}/firewall/access_rules/rules/{rule_id} internet-svcs.security.manage internet-svcs.ip-firewall-rules.delete 
 Get user-agent blocking rules GET /v1/{crn}/zones/{domain_id}/firewall/ua_rules internet-svcs.security.read internet-svcs.ua-rules.read 
 Create a user-agent blocking rule POST /v1/{crn}/zones/{domain_id}/firewall/ua_rules internet-svcs.security.manage internet-svcs.ua-rules.create
Commit the configuration. Then, from your workstation, verify using ping that the firewall is now denying traffic via the VRA to the VSI:

commit

ping <VSI Private IP Address>
5. Define firewall access rules for UDP, TCP and ICMP.

set security firewall name INSIDE-TO-APP rule 200 protocol icmp
set security firewall name INSIDE-TO-APP rule 200 icmp type 8
set security firewall name INSIDE-TO-APP rule 200 action accept
set security firewall name INSIDE-TO-APP rule 200 source address ibmprivate

set security firewall name INSIDE-TO-APP rule 100 action accept
set security firewall name INSIDE-TO-APP rule 100 protocol tcp
set security firewall name INSIDE-TO-APP rule 100 source address ibmprivate

set security firewall name INSIDE-TO-APP rule 110 action accept
set security firewall name INSIDE-TO-APP rule 110 protocol udp
set security firewall name INSIDE-TO-APP rule 110 source address ibmprivate
commit

set security firewall name APP-TO-INSIDE rule 200 protocol icmp
set security firewall name APP-TO-INSIDE rule 200 icmp type 8
set security firewall name APP-TO-INSIDE rule 200 action accept
set security firewall name APP-TO-INSIDE rule 200 destination address ibmprivate

set security firewall name APP-TO-INSIDE rule 100 action accept
set security firewall name APP-TO-INSIDE rule 100 protocol tcp
set security firewall name APP-TO-INSIDE rule 100 destination address ibmprivate

set security firewall name APP-TO-INSIDE rule 110 action accept
set security firewall name APP-TO-INSIDE rule 110 protocol udp
set security firewall name APP-TO-INSIDE rule 110 destination address ibmprivate
commit
Show more
6. Validate firewall access.



* Confirm INSIDE-TO-APP firewall is now allowing ICMP and UPD/TCP traffic from your local machine.

ping <VSI Private IP Address>
SSH root@<VSI Private IP Address>
For example, allowing backend subnets inbound on dp0bond0 would be less work than allowing backend subnets outbound toward each VLAN virtual interface.



 Per-interface firewall rules 

One method for configuring the firewall on a VRA is to apply firewall rule sets to each interface. In this case an interface can be a dataplane interface (dp0s0) or a virtual interface (dp0bond0.303). Each interface has three possible firewall assignments:

in - The firewall is checked against packets entering through the interface. These packets can be traversing or be destined for the VRA.

out - The firewall is checked against packets leaving through the interface. These packets can be traversing or originating on the VRA.

local - The firewall is checked against packets which are destined directly for the VRA.

An interface can have multiple rule sets applied in each direction. They are applied in the order of configuration. Note that it is not possible to firewall traffic originating from the VRA device using per-interface firewalls.

As an example, to assign the ALLOW_LEGACY rule set to the in option for the bp0s1 interface, you would use the configuration command:

set interfaces dataplane dp0s1 firewall in ALLOW_LEGACY







 Control Plane Policing (CPP) 

Control plane policing (CPP) provides protection against attacks on the IBM Cloud® Virtual Router Appliance by allowing you to configure firewall policies that are assigned to desired interfaces and applying these policies to packets entering the VRA.

CPP is implemented when the local keyword is used in firewall policies that are assigned to any type of VRA interface, such as data plane interfaces or loopback. Unlike the firewall rules applied for packets traversing through the VRA, the default action of firewall rules for traffic entering or leaving the control plane is Allow. Users must add explicit drop rules if the default behavior is not desired.

The VRA provides a basic CPP rule set as template. You can merge it into your configuration by running:

vyatta@vrouter merge /opt/vyatta/etc/cpp.conf
Deprecated] ibmcloud cis firewall-rule-update DNS_DOMAIN_ID FIREWALL_RULE_ID (-s, --json-str JSON_STR | -j, --json-file JSON_FILE) -i, --instance INSTANCE] --output FORMAT] ! !!!!!! ! ! ! ! !
<-- <section "id="section-update-a-firewall-rule-options" "> --> Command options DNS_DOMAIN_ID: The ID of DNS domain. Required.FIREWALL_RULE_ID: The ID of firewall-rule. Required.--expression: A filter expression. For example, ip.src eq 93.184.216.0.--action: The rule action to perform. Valid values: log, allow, challenge, js_challenge, block, bypass.--priority: The rule's priority. Valid values: 0 2147483647. Value 0 means to set to the default value.--description: To briefly describe the rule.--paused: Indicates if the rule is active. Valid values: on, off. Default value is off.--products: The list of security products to be bypassed. Valid values: zoneLockdown, uaBlock, bic, hot, securityLevel, rateLimit, waf.--json: The JSON file or JSON string used to describe a firewall-rule.
<-- <ul> -->

* The required fields in JSON data are expression, action.

<-- <ul> -->

* expression: A filter expression. For example, ip.src eq 93.184.216.0
* action: The rule action to perform. Valid values: log, allow, challenge, js_challenge, block, bypass.

<-- </ul> -->

* The optional fields are description, priority, paused, products.

<-- <ul> -->

* description: To briefly describe the rule.
* priority: The rule's priority.
set service nat source rule 10 outbound-interface 'dp0bond1'
set service nat source rule 10 protocol 'tcp'
set service nat source rule 10 source address '10.1.2.3'
set service nat source rule 10 translation address '150.1.2.3'

150.1.2.3 would be a public address for the VRA.

It is recommended to use the VRRP public address of the VRA so that you can differentiate between host and VRA public traffic.

Assume that 150.1.2.3 is the VRRP VRA address, and 150.1.2.5 is the real dp0bond1 address. The stateful firewall applied on dp0bond1 out would be:

set security firewall name TO_INTERNET default-action drop
set security firewall name TO_INTERNET rule 10 action accept
set security firewall name TO_INTERNET rule 10 description 'Accept host traffic to Internet - SNAT to VRRP'
set security firewall name TO_INTERNET rule 10 source address '150.1.2.3'
set security firewall name TO_INTERNET rule 10 state 'enable'
set security firewall name TO_INTERNET rule 20 action accept
set security firewall name TO_INTERNET rule 20 description 'Accept VRA traffic to Internet'
set security firewall name TO_INTERNET rule 20 source address '150.1.2.5'
set security firewall name TO_INTERNET rule 20 state 'enable'

The combination of Source NAT and firewall achieves the required design goal.

Ensure that the rules are appropriate for your design, and that no other rules allow traffic that should be blocked.





 How do I protect the VRA itself with a zone-based firewall? 

The VRA does not have a local zone. You can use the Control Plane Policing (CPP) functionality instead as it is applied as a local firewall on loopback.

This is a stateless firewall and you must explicitly allow the returning traffic of outbound sessions that originate on the VRA itself.





 How do I restrict SSH and block connections that come from the internet?