vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* Specific URLs - For example, you can allow IP 1.2.3.4 access to directory example.com/foo/ and allow IP 5.6.7.8 access to directory example.com/bar/, but not allow the reverse.



This capability is useful when you need more granularity in your access rules because, with IP rules, you can either apply the block to all subdomains of the current domain, or all domains on your account. You cannot specify URIs.







 Firewall rules 

Create rules that examine incoming HTTP traffic against a set of filters to block, challenge, log, or allow matching requests.

In general, firewall rules are designed for properties that are exposed in OSI Layer-7 (HTTP), such as request headers and body content characteristics. Therefore, firewall rules apply to HTTP/HTTPS [Range](https://cloud.ibm.com/docs/cis?topic=cis-cis-range) apps.





 Events 

View events that are triggered by an active web application firewall rule. For each event, you can change the triggered action based on the requesting IP address, or the requesting region as a whole.





 Range 

Extend the power of CIS DDoS, TLS, and IP firewall to your web servers and your TCP-based services by using Range applications, keeping them online and secure.





 Advanced security 

Advanced security settings include the following features, which you can change, enable, or disable.



* Browser integrity check - The browser integrity check looks for HTTP headers that are commonly abused by spammers. It denies traffic with those headers access to your page. It also blocks or challenges visitors that do not have a user agent, or who add a nonstandard user agent. This tactic is commonly used by abuse bots, crawlers, or APIs.
* Challenge passage - Controls how long a visitor that passed a challenge (or JavaScript challenge) gains access to your site before they are challenged again. This challenge is based on the visitor's IP, and therefore does not apply to challenges presented by WAF rules because they are based on an action that the user performs on your site.
* Security level - Sets the security level of your website to determine which visitors receive a challenge page.
* 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.

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





 Examples 

Get firewall rule details.

ibmcloud cis firewall dc014906ccce4e7ea2e28be7df70d0d2 -t access-rules -i "cis-demo"
ibmcloud cis firewall bc014906ccce4e7ea2e28be7df70d0d2 -t access-rules -d 31984fea73a15b45779fa0df4ef62f9b -i "cis-demo"
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.
set security firewall name ALLOW_LEGACY rule 1 action drop
set security firewall name ALLOW_LEGACY rule 1 source address network-group1
set security firewall name ALLOW_LEGACY rule 2 action drop
set security firewall name ALLOW_LEGACY rule 2 destination port 23
set security firewall name ALLOW_LEGACY rule 2 log
set security firewall name ALLOW_LEGACY rule 2 protocol tcp
set security firewall name ALLOW_LEGACY rule 2 source address network-group2

In the ruleset, ALLOW_LEGACY, there are two rules defined. The first rule drops any traffic sourced from an address group named network-group1. The second rule discards and logs any traffic destined for the telnet port (tcp/23) from the address group named network-group2. The default-action indicates that anything else is accepted.





 Allowing data center access 

IBM© offers several IP subnets to provide services and support to systems running within the data center. For example, DNS resolver services are running on 10.0.80.11 and 10.0.80.12. Other subnets are used during provisioning and support. You can find the IP ranges used in the data centers in [this topic](https://cloud.ibm.com/docs/hardware-firewall-dedicated?topic=hardware-firewall-dedicated-ibm-cloud-ip-ranges).

You can allow data center access by placing the proper SERVICE-ALLOW rules at the beginning of the firewall rule sets with an action of accept. Where the rule set must be applied depends on the routing and firewall design being implemented.

It is recommended that you place the firewall rules in the location which causes the least duplication of work. 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:
* Creates a distributed firewall policy that is named Cyber-Isolated, which contains the following rules to satisfy their isolation requirements:





Table 2. 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 the 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 the two segments Isolated-NW2 and Isolated-NW3 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 cyber-tools 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

![Immutable backup environment sandbox example](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/veeam-cr-sa-sb-ire-detail.svg)

Figure 2. Immutable backup environment sandbox example



 Related links
Bypassing the Hardware Firewall rules 

You can bypass the rules of your Hardware Firewall 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 select the firewall protected device you want to bypass.
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 Bypass Rules. Click OK to confirm the action. Bypassing the rules takes approximately two minutes to take effect. While in bypass mode, the status icon will change to yellow, and show a "Bypassing all rules" message.





  Enabling the rules again 

To enable the rules again, follow the instructions above to reach the Firewall Details page of the device and click on the Actions dropdown menu. Choose Process Rules. Click OK to confirm the action. Within two minutes, the status icon will change back to green and show a "Processing all rules" message.

The Process Rules action will be disabled if the firewall does not have any rules defined.
In general, firewall rules are designed for properties exposed in OSI Layer 7 (HTTP), such as request headers and body content characteristics.





 Adding an application using the console 

Follow these steps to add an application using the UI.

In the console, UDP applications must be enabled through a Support case. After the functionality is enabled, you can create a UDP application through the CLI or API.



1. Navigate to Security > Range.
2. Click Create.
3. Select a type of application from the list menu. You can choose TCP, UDP, HTTP, HTTPS, RDP, SSH, or Minecraft.
4. Enter the application name. Your application becomes associated with a DNS name on your CIS domain.
5. Enter the edge port. CIS listens for incoming connections to these addresses on this port. Connections to these addresses are proxied to your origin. You can enter a port range (for example: 8080-8090), but the origin must have the same quantity of ports specified in a consecutive range.
6. Select the edge IP connectivity.
7. In the Origin section, enter the origin IP and port of your TCP application. You can also select an existing load balancer and its port.
8. Enable IP firewall (optional). When enabled, firewall rules with a "block" or "allowlist" action are enforced for this application.
9. Enable edge TLS termination (optional). When enabled, select the type of TLS termination you want to use from the list menu.
10. Select a [PROXY Protocol](https://cloud.ibm.com/docs/cis?topic=cis-enable-proxy-protocol) if you have a proxy in-line that supports PROXY Protocol (optional). This feature is useful if you are running a service that requires knowledge of the true client IP. In most cases, this setting remains off.
11. Click Create.



Provisioning a Range application incurs additional costs, based on the amount of bandwidth used per application.
Managing permissions 

To view and manage your hardware firewalls, you need the correct permissions. After your account administrator grants your user account permissions and access, you can view your hardware firewall details by using the IBM Cloud® console, or by using the SoftLayer API. The information or actions that you see depend on your permissions.

The following permissions are required for viewing and managing various parts of your hardware firewalls:



*  Manage firewalls - Allows you to view your list of firewalls. It also allows you to view and manage the details of a specific firewall.
*  View hardware details - Allows you to view your list of hardware firewalls on bare metal servers. It also allows you to view and manage the details of a specific hardware firewall on a bare metal server.
*  View virtual server details - Allows you to view your list of firewalls on virtual servers. It also allows you to view and manage the details of a specific hardware firewall on a virtual server.
*  Manage firewall rules - Allows you to manage the rules of a specific hardware firewall.
*  Cancel services - Allows you to cancel a firewall.





  Adding permissions for your users 

If you are the account administrator and you want to grant a user permission to view and manage gateway appliance details, complete the following steps.



1.  Log in to the [Access (IAM)](https://cloud.ibm.com/iam/users) page in the IBM Cloud® console.
2.  Select View: My classic infrastructure users.
3.  Select a user, click the Classic infrastructure tab, then click the Permissions tab.
4.  Expand the Devices category and select Manage firewalls.
5.  Expand the Devices category and select View hardware details.
6.  Expand the Devices category and select View virtual server details.
7.  Expand the Devices category and select Manage firewall rules.
8.  Expand the Account category and select Cancel services.
9.  Click Apply.







  Next steps 

User permissions are updated immediately after the changes are submitted. If permissions are granted, the user can view or interact with the selected features. If permissions are removed, the user can no longer view or interact with the selected features. Permissions can be updated again at any time.
Adding firewall functions to Vyatta 5400 (stateless and stateful) 

Applying firewall rulesets to each interface is one firewall method when you use Brocade 5400 vRouter (Vyatta) devices. Each interface has three possible firewall instances - In, Out, and Local - and each instance has rules that can be applied to it. The default action is Drop, with rules that allow specific traffic being applied in a fashion from rule 1 to N. As soon as a match is made, the firewall applies the specific action of the matching rule.

For any of the following firewall instances, only one can be applied.



* IN - The firewall filters packets that enter the interface and traverse the Brocade system. You must permit certain SoftLayer IP ranges to have access to the front-end and back-end for management (ping, monitoring, and so on).
* OUT - The firewall filters packets leaving the interface. These packets can be traversing the Brocade system or originating on the system.
* LOCAL - The firewall filters packets that are destined for the Brocade vRouter system through the system interface. You should establish restrictions on access ports coming into the Brocade vRouter device from external IP addresses that are not restricted.



Follow these steps to set an example firewall rule to turn off Internet Control Message Protocol (ICMP)(ping - IPv4 echo reply message) to your Brocade 5400 vRouter's interfaces (this is a stateless action; a stateful action is reviewed later):



1. Type show configuration commands in the command prompt to see which configurations are set. You see a list of all the commands that you set on your device (which can be handy if you decide to migrate and want to see all your configurations). Notice the command set firewall all-ping 'enable', which indicates that ICMP is still enabled for your device.
2. Type configure.
3. Type set firewall all-ping 'disable'.
4. Type commit.



If you now try to ping your Brocade 5400 vRouter device, no response is received.
For example, bypass the WAF for a specific URL and a specific IP address or user agent.
* Disable WAF for traffic to a URL (not recommended). Disabling WAF using page rules lowers security on the particular URL endpoint.



If you contact IBM Support to verify whether a WAF rule triggers as expected, provide a HAR file captured while sending the specific request of concern.

If one specific rule causes false positives, set rule’s Mode to Disable rather than turning Off the entire rule group. For false positives with the administrator content on your website, create a page rule to disable security for the admin section of your site resources, for example, yoursite.com/admin.





 Troubleshooting WAF false negatives 

 How to fix it 

To identify false negatives, review the HTTP logs on your origin web server.

To reduce false negatives, use the following checklist:



* Is Web Application Firewall On in the Firewall app under Managed Rules?
* Is Web Application Firewall Off using page rules?
* Not all WAF rules are enabled by default, so review individual WAF rule default actions. For example, CIS allows requests with empty user agents by default.



To block requests with an empty user agent, change the WAF rule Mode to Block.



* Are DNS records that serve HTTP traffic proxied through CIS?
* Does a firewall rule bypass CIS managed rules?
* Does an allowed country, ASN, IP range, or IP in IP access rules or firewall rules match the attack traffic?
* Is the malicious traffic directed at your origin IP addresses to bypass CIS protection? Block all traffic except from CIS's IP addresses at your origin web server.
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 configure.
4. In the Add-ons section, click Firewall details. It will redirect you to the firewall page.
5. The Firewall Details page shows the current rules in effect for IPv4 and IPv6 addresses. If no rules are implemented, a yellow status icon will show with a "Bypassing all rules" message next to the device name on the top of the page.

Rules are displayed in the order in which they are processed, with lower numbered rules having precedence over higher number rules (if rule one allows a packet through, rules two and beyond are ignored by the packet).

The fields are:

Priority - This field contains the rule number. Lower numbered rules have precedence over higher numbered rules.

Action - This select list is used to 'permit' or 'deny' traffic matching this rule.

Source - This field can be either 'any' or a specific IP address or the network address for a specific subnet.

Destination - This field selects the destination IP (see [Known Limitations](https://cloud.ibm.com/docs/hardware-firewall-shared?topic=hardware-firewall-shared-known-limitations-with-hardware-firewall-shared-) if there are issues).

CIDR - This field indicates the standard CIDR notation for the selected source/destination.

Port Range - These two fields indicate the range of ports (between 1 and 65535) that the rule will apply to.

Protocol - This field selects the protocol the rule will apply to (TCP/GRE/ICMP/UDP/PPTP/AH/ESP).

Notes: Freeform field to enter any note about this rule.
6. Click on the Overflow menu icon at the end of the row of the firewall rule to edit or delete the rule.
By default, the IBM Cloud® for VMware as a Service – single tenant instance has been provisioned with a default firewall rule that will drop all traffic for ensuring basic network security. Additional rules must be put in place to allow the traffic from the previously created network to access the Public Internet and for you to access the virtual machine from the Public Internet.



Firewall rules

 Name Applications Source Destination Action IP protocol 

 dnat-to-jump RDP, ICMP ALL Any ipset-dnat-to-jump Allow IPv4 
 egress-to-inet N/A sg-private-networks Any Allow IPv4 
 default_rule N/A Any Any Drop IPv4 



The default_rule has been pre-provisioned by IBM Cloud. It is listed above just for illustration purposes.

To create a firewall rule:



1. In the top menu navigation, click on Networking.
2. Click on Edge Gateways and select your virtual data center's Edge Gateway.
3. In the left navigation under Services, click on Firewall.
4. Click on Edit Rules.
5. Click on New on Top to create a new firewall rule above the default_rule (drop any).
6. A new entry in the firewall rule list will be created. To complete the entry:



1. Name – In this example, dnat-to-jump is used.
2. Application - Click on the pencil icon next to Applications and select RDP and ICMP ALL from the applications list. You can filter with a name. Click on Save when complete.
3. Source – Click on the pencil icon next to source and toggle the slider next to Any source to green (enabled). Click on Keep when complete.
4. Destination – Click on the pencil icon next to destination and select IP Set ipset-dnat-to-jump (or Static Group if that would have been used). Click on Keep when complete.



7. Review the inputs and click on Save when complete.



The new firewall rule will be created. This may take a few seconds to complete.
You see a list of all the commands that you set on your device (which can be handy if you decide to migrate and want to see all your configurations). Notice the command set firewall all-ping 'enable', which indicates that ICMP is still enabled for your device.
2. Type configure.
3. Type set firewall all-ping 'disable'.
4. Type commit.



If you now try to ping your Brocade 5400 vRouter device, no response is received.

To assign firewall rules to routed traffic, you must apply rules to the Brocade 5400 vRouter's interfaces or create zones, then apply to the zones.

For this example, zones are created for the VLANs that were used thus far.

bond1 = dmz

bond1.2007 = prod (for production)

bond0.2254 = private (for development)

bond1.1280 = reserved for future use

bond1.1894 = reserved for future use



 Creating firewall rules 

Before the zones are created, it is a good idea to create the firewall rules that are to be applied to the zones. Creating the rules before the zones allows you to apply them immediately, versus creating the zone, then creating the rules, and having to go back to the zone for rule application.

NOTE: Zones and rulesets both have a default action statement. When using Zone-Policies, the default action is set by the zone-policy statement and is represented by rule 10,000. It is also important to remember that the default action of a firewall ruleset is to drop all traffic.

The following commands:



* Create a firewall rule named dmz2private with the default action to drop any packet.
* Enable logging of accepted and denied traffic for the rule named dmz2private.





1. Type configure in the command prompt.
2. Enter the following commands in the prompt:



* set firewall name dmz2private default-action drop
* set firewall name dmz2private enable-default-log
Next, you can create and apply Calico policies to allow traffic from only certain source IPs.





 Step 3: Allow incoming traffic from a specific IP to the NLB 

You now decide to completely lock down traffic to the PR firm's cluster and test access by allowing only your own computer's IP address.

First, in addition to the node ports, you must block all incoming traffic to the NLB exposing the app. Then, you can create a policy that allows your system's IP address. At the end of Lesson 3, all traffic to the public node ports and NLB is blocked and only traffic from your allowed system IP is allowed.

Zoom

![The web server app is exposed by public NLB to your system IP only.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_tutorial_policies_L3.png)

Figure 3. The webserver app is exposed by public NLB to your system IP only.



1. In a text editor, create a high-order Pre-DNAT policy called deny-lb-port-80.yaml to deny all incoming TCP and UDP traffic from any source IP to the NLB IP address and port. Replace <loadbalancer_IP> with the NLB public IP address from your cheat sheet.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: deny-lb-port-80
spec:
applyOnForward: true
preDNAT: true
ingress:
- action: Deny
destination:
nets:
- <loadbalancer_IP>/32
ports:
- 80
protocol: TCP
source: {}
- action: Deny
destination:
nets:
- <loadbalancer_IP>/32
ports:
- 80
protocol: UDP
source: {}
selector: ibm.role=='worker_public'
<br><br> * Isolate management VPC and allow only a limited number of network connections<br> * All other connections from or to management VPC are forbidden<br><br><br> ACL and security group rules in management VPC More ports might be opened in preset or added manually after deployment 
 <br><br> * Isolate workload VPC and allow only a limited number of network connections<br> * All other connections from or to workload VPC are forbidden<br><br><br> ACL and security group rules in workload VPC More ports might be opened in preset or added manually after deployment 
 Load VPN configuration to simplify VPN setup VPNs VPN configuration is the responsibility of the customer