vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Use the following commands to set the firewall policy for the zones:



* set zone-policy zone private from dmz firewall name dmz2private
* set zone-policy zone prod from dmz firewall name dmz2private
* set zone-policy zone dmz from prod firewall name public4
* commit





Note that you can apply a firewall rule to a specific interface if you do not want to apply it to a zone policy. Use the following commands to apply a rule to an interface.



* set interfaces bonding bond1 firewall local name public
* commit







 Stateful firewalls 

A stateful firewall keeps a table of previously seen flows, and packets can be accepted or dropped according to their relation with previous packets. Generally, stateful firewalls are preferred where application traffic is prevalent.

The Brocade 5400 vRouter does not track the state of the connections with default configuration. The firewall is stateless until one of the following conditions is met:



* Configuration of a firewall and any rule has a state parameter set
* Configuration of a firewall state-policy
* Configuration of NAT
* Enablement of the transparent web proxy service
* Enablement of a WAN load-balancing configuration







 Stateless firewalls 

A stateless firewall considers every packet in isolation. Packets can be accepted or dropped according to only basic access control list (ACL) criteria, such as the source and destination fields in the IP or Transmission Control Protocols/User Datagram Protocol (TCP/UDP) headers. A stateless Brocade 5400 vRouter does not store connection information and has no requirement to look up every packet's relation to previous flows, both of which consume small amounts of memory and CPU time. Therefore, raw forwarding performance is best on a stateless system. Brocade recommends keeping the router stateless for best performance if you do not require the features specific to statefulness.
* How can I filter internet-bound traffic and only allow specific protocols and destinations?

This is a common question when Source NAT and a firewall must be combined.

Keep in mind the order of operations in the VRA you design your rulesets.

In short, firewall rules are applied after SNAT.

To block all outgoing traffic in a firewall, but allow specific SNAT flows, you must move the filtering logic onto your SNAT. For example, to only allow HTTPS internet-bound traffic for a host, the SNAT rule would be:

set service nat source rule 10 description 'SNAT https traffic from server 10.1.2.3 to Internet'
set service nat source rule 10 destination port 443
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'
* 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



The next set of commands is to enable iptables to allow traffic for an established session to return. By default, iptables does not allow this, which is why an explicit rule is required.



* set firewall name dmz2private rule 1 action accept
* set firewall name dmz2private rule 1 state established enable
* set firewall name dmz2private rule 1 state related enable



The third set of commands allows TCP/UDP to get through port 22, the default for SSH.



* set firewall name dmz2private rule 2 action accept
* set firewall name dmz2private rule 2 protocol tcp_udp
* set firewall name dmz2private rule 2 destination port 22



The final set of commands allows TCP/UDP to get through port 80, the default for HTTP.



* set firewall name dmz2private rule 3 action accept
* set firewall name dmz2private rule 3 protocol tcp_udp
* set firewall name dmz2private rule 3 destination port 80



3. Type commit to ensure that all rules are taken when finished.
4. View your configuration by typing show firewall name dmz2private in the command prompt.



The next firewall rule is applied to our dmz zone. This rule is named public. Enter the following commands:



* set firewall name public default-action drop
* set firewall name public enable-default-log
* set firewall name public rule 1 action accept
* set firewall name public rule 1 state established enable
* set firewall name public rule 1 state related enable
* Turn on WAF using the toggle on the Web Application Firewall page. When you toggle the rules on or off, the changes are applied immediately.
* Enterprise only - The Rate limiting page allows you to configure rate limiting rules to avoid noisy-neighbor problems and ward off DDoS.
* On the IP Firewall page, you can configure access rules based on IP, country code, or ASN. You can also configure rules to block user agents. The domain lockdown section of this page allows you to limit access to your domain to certain IP addresses.
* You can review firewall-related events on the Events page.







 Certificates 

When you configure a domain, IBM CIS automatically deploys a universal certificate for that domain. Thus, you don't need to do anything to have certificate-based protection in that domain. If you want, you can upload your own self-managed certificate. You'll need a separate certificate for each domain, and you'll see an error message if the certificate you are uploading does not match your domain. You can also order custom certificates on this page.

If you want to upload your own certificate, you must ensure that you replace expiring certificates before they expire, otherwise your visitors might not be able to connect. Enterprise plan users can set up an expiration notice using the [Alerts feature](https://cloud.ibm.com/docs/cis?topic=cis-configuring-policies&interface=ui).
Assigning firewall rule actions 

Firewall rule actions tell CIS how to respond to requests that match the criteria you define.

For lightweight firewall rules, navigate to Security > IP firewall, which contains IP rules, User Agent rules, and Domain Lockdown rules. Firewall rules are based on IP address, IP address range, Autonomous System Number (ASN), or country/region.

Domain lockdown rules specify a list of IP addresses, CIDR ranges, or networks that can access a domain, subdomain, or URL. Anything not on the list is blocked.

For more robust firewall rules, navigate to Security > Firewall rules, where you can create rules that examine incoming HTTP traffic against a set of filters to block, challenge, log, or allow matching requests.

The following table describes the actions that you can assign to your rules. The priority column shows what precedence the action receives. If a request matches two different rules that have the same priority, precedence determines the action to take.



Table 1. Firewall rule actions and priority

 Action Available in Description Priority 

 Log <br><br> * Firewall rules<br><br><br> Logs matching requests on the CIS edge for access with Enterprise Logpush and Logpull. Recommended for testing rule effectiveness you commit to a more severe action. Available to Enterprise customers only. 1 
 Bypass <br><br> * Firewall rules<br><br><br> Allows dynamic disabling of security features for a request. Exempts matching requests from evaluation, based on a user-defined list that contains one or more of the following features: Browser Integrity Check, Domain Lockdown, Hotlink Protection, Rate Limiting, Security Level, User Agent Block, WAF Managed Rules. Matching requests are still subject to evaluation within Firewall Rules, based on order of execution. 2 
 Allow <br><br> * Firewall rules<br> * IP firewall<br><br><br> Allows matching requests to access the site, on condition that no other CIS firewall features block the request, such as IP firewall or access rules. 3
Managing firewalls 

IBM Cloud® Virtual Router Appliance (VRA) has the ability to process firewall rules to protect the VLANs routed through the device.

The firewalls in the VRA can be broken into two steps:



1. Defining one or more sets of rules.
2. Applying a set of rules to an interface or a zone. A zone consists of one or more network interfaces.



It is important to test firewall rules after creation to ensure the rules work as intended and that new rules do not restrict administrative access to the device.

While manipulating rules on the dp0bond1 interface, it is advised to connect to the device using dp0bond0. Connecting to the console using the Intelligent Platform Management Interface (IPMI) is also an option.



 Stateless vs stateful 

By default, the firewall is stateless, but it can be configured as stateful if needed. A stateless firewall will need rules for traffic in both directions, while stateful firewalls track connections and automatically allow the returning traffic of accepted flows. To configure a stateful firewall, you must dictate which rules you want to operate statefully.

To enable 'stateful' tracking of tcp, udp, or icmp traffic, run the following commands:

set security firewall global-state-policy icmp
set security firewall global-state-policy tcp
set security firewall global-state-policy udp

Note that the global-state-policy commands will only track the state of traffic that has matched a firewall rule which explicitly sets the corresponding protocol. For example:

set security firewall name GLOBAL_STATELESS rule 1 action accept

As GLOBAL_STATELESS does not specify protocol tcp, the global-state-policy tcp command would not apply on this rule.

set security firewall name GLOBAL_STATEFUL_TCP rule 1 action accept
set security firewall name GLOBAL_STATEFUL_TCP rule 1 protocol tcp

In this case protocol tcp is explicitly defined. The global-state-policy tcp command would enable stateful tracking of traffic that matches rule 1 of GLOBAL_STATEFUL_TCP
The following is an example of SERVICE-ALLOW. This is not a complete private IP rule set.

set firewall name SERVICE-ALLOW rule 1 action 'accept'
set firewall name SERVICE-ALLOW rule 1 destination address '10.0.64.0/19'
set firewall name SERVICE-ALLOW rule 2 action 'accept'
set firewall name SERVICE-ALLOW rule 2 destination address '10.1.128.0/19'
set firewall name SERVICE-ALLOW rule 3 action 'accept'
set firewall name SERVICE-ALLOW rule 3 destination address '10.0.86.0/24'

After you define the firewall rules, you can assign them as you see fit. Two examples are listed.

Applying to a zone: set zone-policy zone private from dmz firewall name SERVICE-ALLOW

Applying to a bond interface: set interfaces bonding bond0 firewall local name SERVICE-ALLOW
As GLOBAL_STATELESS does not specify protocol tcp, the global-state-policy tcp command would not apply on this rule.

set security firewall name GLOBAL_STATEFUL_TCP rule 1 action accept
set security firewall name GLOBAL_STATEFUL_TCP rule 1 protocol tcp

In this case protocol tcp is explicitly defined. The global-state-policy tcp command would enable stateful tracking of traffic that matches rule 1 of GLOBAL_STATEFUL_TCP

To make individual firewall rules 'stateful':

set security firewall name TEST rule 1 allow
set security firewall name TEST rule 1 state enable

This would enable stateful tracking of all traffic that can be tracked statefully and matches rule 1 of TEST, regardless of the existence of global-state-policy commands.





 ALG for assisted stateful tracking 

A few protocols such as FTP utilize more complex sessions that the normal stateful firewall operation can track. There are preconfigured modules that enable these protocols to be statefully managed.

It is suggested to disable these ALG modules, unless they are required for the successful use of the respective protocols.

set system alg ftp 'disable'
set system alg icmp 'disable'
set system alg pptp 'disable'
set system alg rpc 'disable'
set system alg rsh 'disable'
set system alg sip 'disable'
set system alg tftp 'disable'





 Firewall rule sets 

Firewall rules are grouped together into named sets to make applying rules to multiple interfaces easier. Each rule set has a default action associated with it. Consider the following example:

set security firewall name ALLOW_LEGACY default-action accept
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
Creating, editing, and deleting firewall rules 

IBM Cloud® Internet Services firewall rules offer power and flexibility by targeting HTTP traffic and applying custom criteria to block, challenge, log, or allow certain requests.

You can create many types of firewall rules. However, the number of active rules on your site is limited by your customer plan. See the [Plan comparison](https://cloud.ibm.com/docs/cis?topic=cis-cis-plan-comparison) page for more information on entitlements.

The number of active rules per plan is fixed. You cannot purchase additional active rules at this time.

Before getting started, it's a good idea to become familiar with [Using fields, functions, and expressions](https://cloud.ibm.com/docs/cis?topic=cis-fields-and-expressions).



 Creating a firewall rule 

Take the following steps to configure a basic firewall rule:



1. Navigate to Security > Firewall Rules.
2. Click Create Firewall Rule.
3. Enter a rule name and optional description.
4. Optionally, input a priority, if necessary. Note that a priority of zero is a null priority and is evaluated last.
5. Use the UI builder in the Incoming requests section to add a condition. To build an expression with multiple conditions, click either:



* And - to evaluate conditions using and logic
* Or - to evaluate conditions or groups of previously and'ed conditions using or logic



You can see that as you build a condition, the Expression Preview shows the expression in plain text.

In the Expression Preview, you can click to edit your expression manually instead of using the Visual Expression Builder, or switch between the two. However, depending on the complexity of a manually constructed expression, the Visual Expression Builder might be unable to render it.
6. Pick an action from the Response list menu.
7. To save your rule, choose the most appropriate option by clicking either:



* Save as draft to save your rule, but leave it disabled.
* Save and deploy to save your rule and activate it.









 Editing a firewall rule
The distributed firewall policy configuration in a policy named Cyber-Isolated is defined as:



Table 4. NSX-T distributed firewall policy

 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 





 Related links 



* [Tier-1 logical router](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-DAEF8457-8363-4F33-84DA-68AA36A2DE3C.html)
* [Network Address Translation (NAT)](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-7AD2C384-4303-4D6C-A44A-DEF45AA18A92.html)
* [Distributed firewall](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-6AB240DB-949C-4E95-A9A7-4AC6EF5E3036.html)
* [Tags](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-358DF469-75C8-48C4-B0E2-279E55C7BB3E.html)
* [Segments](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-316E5027-E588-455C-88AD-A7DA930A4F0B.html)
Working with firewalls 

The IBM Cloud® Juniper vSRX uses the concept of security zones, where each vSRX interface is mapped to a "zone" for handling stateful firewalls. Stateless firewalls are controlled by firewall filters.

Policies are used to allow and block traffic between these defined zones, and the rules defined here are stateful.

In the IBM Cloud, a vSRX is designed to have four different security zones:



Table 1. Security zones

 Zone Standalone Interface HA Interface 

 SL-Private (untagged) ge-0/0/0.0 or ae0.0 reth0.0 
 SL-Public (untagged) ge-0/0/1.0 or ae1.0 reth1.0 
 Customer-Private (tagged) ge-0/0/0.1 or ae0.1 reth2.1 
 Customer-Public (tagged) ge-0/0/1.1 or ae1.1 reth3.1 





 Zone policies 

To configure a stateful firewall, follow these steps:



1. Create security zones and assign the respective interfaces:

Standalone scenario:

set security zones security-zone CUSTOMER-PRIVATE interfaces ge-0/0/0.1
set security zones security-zone CUSTOMER-PUBLIC interfaces ge-0/0/1.1

High Availability scenario:

set security zones security-zone CUSTOMER-PRIVATE interfaces reth2.1
set security zones security-zone CUSTOMER-PUBLIC interfaces reth2.1
2. Define the policy and rules between two different zones.

The following example illustrates pinging traffic from the zone Customer-Private to Customer-Public:

set security policies from-zone CUSTOMER-PRIVATE to-zone CUSTOMER-PUBLIC policy ALLOW_ICMP match source-address any destination-address any application junos-icmp

set security policies from-zone CUSTOMER-PRIVATE to-zone CUSTOMER-PUBLIC policy ALLOW_ICMP then permit



These are some of the attributes that can be defined in your policies:



* Source addresses
* Destination addresses
* Applications
* Action (permit/deny/reject/count/log)
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 44.578/44.750/44.993/0.244 ms

This illustrates bidirectional traffic across this IPsec tunnel. Next, you can apply a simple "allow all" zone policy to all interfaces on Machine A:

set security firewall name ALLOWALL default-action 'drop'
set security firewall name ALLOWALL rule 10 action 'accept'
set security firewall name ALLOWALL rule 10 protocol 'tcp'
set security firewall name ALLOWALL rule 10 state 'enable'
set security firewall name ALLOWALL rule 20 action 'accept'
set security firewall name ALLOWALL rule 20 protocol 'icmp'
set security firewall name ALLOWALL rule 20 state 'enable'
set security firewall name ALLOWALL rule 30 action 'accept'
set security firewall name ALLOWALL rule 30 protocol 'udp'
set security firewall name ALLOWALL rule 30 state 'enable'

Then, add policies between all three interfaces:

set security zone-policy zone INTERNET interface 'dp0bond1'
set security zone-policy zone INTERNET to PRIVATE firewall 'ALLOWALL'
set security zone-policy zone INTERNET to SERVERS firewall 'ALLOWALL'
set security zone-policy zone PRIVATE interface 'dp0bond0'
set security zone-policy zone PRIVATE to INTERNET firewall 'ALLOWALL'
set security zone-policy zone PRIVATE to SERVERS firewall 'ALLOWALL'
set security zone-policy zone SERVERS interface 'dp0bond0.1341'
set security zone-policy zone SERVERS to INTERNET firewall 'ALLOWALL'
set security zone-policy zone SERVERS to PRIVATE firewall 'ALLOWALL'

After the policies are applied, traffic no longer flows, despite being set to allow all.
A policy can have an unlimited number of rules, or no rules. An RBAC Policy with no rules, containing only the Default Permission, can be used to apply simple data masking for all Users which connect to the Shield.

a. Enter a Rule Name of 30 characters or less.

b. Select relevant User Groups from the drop-down list. All User Groups are available, but only one Rule will be considered per User. See step 5.

c. Select a Permission option from the drop-down: READ, READ_WRITE, or MASK.

MASK permission allows you to specify an existing Masking mode for a given user group. In other words, upon accessing the data, members of that group view the data in the mask format that you specify.
5. RBAC policy rules must be arranged in a hierarchy. Reorder the rules by clicking the Up and Down arrows to update the Rank number in the policy.

Technically, an individual database user can have membership to more than one user group. However, this exposes a potential contradiction where multiple rules could apply to an individual database user. To avoid this, Rules must be arranged in a hierarchy, where only the highest-ranked rule is considered for each user group, and each user.
6. Optional: Create another rule by clicking + Rule. Rules can be collapsed, expanded and deleted. When collapsed, only the Rule Name and Rank are visible.
7. When you are done with the policy, click Save. Role-Based Access Control is fully configured, and ready to apply to columns.
8. Optional: After saving the policy, create another User Group or create another RBAC Policy.
9. Continue with applying an RBAC policy to the database columns.
View your configuration by typing show firewall name dmz2private in the command prompt.



The next firewall rule is applied to our dmz zone. This rule is named public. Enter the following commands:



* set firewall name public default-action drop
* set firewall name public enable-default-log
* set firewall name public rule 1 action accept
* set firewall name public rule 1 state established enable
* set firewall name public rule 1 state related enable



Firewall rules need to flow outbound through prod to dmz. Use the following command to help troubleshoot network flow: sudo tcpdump -i any host 10.52.69.202.





 Creating zones 

Zones are logical representation of an interface. The following commands:



* Create a zone and a policy named dmz with a default action to drop packets that are destined for this zone.
* Set the dmz policy to use the bond1 interface.
* Set the prod policy to use the bond1.2007 interface.
* Create a zone policy named private with a default action to drop packets that are destined for this zone.
* Set the policy named private to use the bond0.2254 interface.





1. Enter the Following commands in the prompt:



* configure
* set zone policy zone dmz default-action drop
* set zone-policy zone dmz interface bond1
* set zone-policy zone prod default-action drop
* set zone-policy zone prod interface bond1.2007
* set zone-policy zone private default-action drop
* set zone-policy zone private interface bond0.2254



2. Use the following commands to set the firewall policy for the zones:



* set zone-policy zone private from dmz firewall name dmz2private
* set zone-policy zone prod from dmz firewall name dmz2private
* set zone-policy zone dmz from prod firewall name public4
* commit





Note that you can apply a firewall rule to a specific interface if you do not want to apply it to a zone policy.