12.4 Transcripciones encuentros metodológicos:
12.4.2 Transcripción segundo encuentro metodológico:
Link to Online Topic Content
Configuring Virtual Servers
When creating virtual server objects in the config utility or the GUI you will need to do a few tasks prior to jumping into building the virtual server. It is true that you can create a simple virtual server in the GUI without doing anything prior because the GUI will allow you to build the Pool and Node objects on the fly inside the virtual server creation task.
If you are creating a new virtual server in the config utility you will have to create all necessary configuration objects that the virtual server will need to use for its creation.
It is always a good idea to have an established object naming convention figured out prior to configuring any objects as well as a good understanding of IP addresses to be used for the virtual server creation.
The objects you should create are as follows:
1. Health monitors for nodes and pool members 2. SNAT pools
3. Any necessary profiles 4. Any necessary iRules
5. Nodes that will be used in the pool members 6. Pool and pool members
1.13 - Describe the security options when creating a virtual server (i.e., VLAN limitation, route domains, packet filters, iRules)
Virtual Server Security
A virtual server is essentially a listener that will be taking in and processing traffic on the BIG-IP platform. Some of the biggest security risks when configuring a virtual server are how it is listening, where it is listening and who can get to it. If you are configuring a virtual server and not setting the necessary settings to restrict these areas of concern you are opening your self up to security risks.
How Is The Virtual Server Listening?
The broader you set a virtual server to listen the greater the risk of unintended inbound traffic. An application based virtual server should typically be configured to listen on the default port for the application. For example if you are configuring a virtual server for a new HTTP based website you would listen on port 80. If you listen on all ports (*), the virtual server will take in traffic destine for the virtual server on all 65535 ports of the IP address. And if the pool members for the virtual server are also listening on all ports (*), it will send traffic to the servers on the port it arrived on the virtual server.
If you need to listen on multiple ports for the same IP address you can approach this in two different ways. You can build a virtual server for each necessary port using the same IP address or you can build one virtual server on all ports and use an iRule to restrict the allowed inbound connections to your list of ports.
Where is the Virtual Server Listening?
When you configure a virtual server you tell the BIG-IP where you want it to listen for traffic destined for the IP address of the virtual server. This virtual server setting is the VLAN and Tunnel Traffic setting. By default the setting is set to All VLANs and Tunnels.
Which means the BIG-IP will listen on all VLANs. You are probably thinking, ARP is only going to happen on the local subnet’s VLAN, which is true. So what can it possibly mean to listen on all VLANs? When this setting is set to all VLANs it means that if traffic comes to BIG-IP destined for the virtual server address from a VLAN that is not the VLAN of the virtual server IP address, it will still take the traffic in on VLAN interface that it arrived on. BIG-IP is a default deny device but in setting the setting to All VLANS and Tunnels you have told the system to listen on all VLANs for traffic to the virtual server and allow it in.
Link to Online Topic Content
Route Domains
A route domain is a configuration object that isolates network traffic for a particular application on the network.
Because route domains segment network traffic, you can assign the same IP address or subnet to multiple nodes on a network, provided that each instance of the IP address resides in a separate routing domain in the BIG-IP system. This feature will allow you to isolate traffic and let upstream devices such as firewalls apply policy to the connections between systems.
Link to Online Topic Content
Packet Filters
Packet filters enhance network security by specifying whether a BIG-IP system interface should accept or reject certain packets based on criteria that you specify. Packet filters enforce an access policy on incoming traffic. They apply to incoming traffic only.
You implement packet filtering by creating packet filter rules, using the BIG-IP
Configuration utility. The primary purpose of a packet filter rule is to define the criteria that you want the BIG-IP system to use when filtering packets. Examples of criteria that you can specify in a packet filter rule are:
The source IP address of a packet
The destination IP address of a packet
The destination port of a packet
You specify the criteria for applying packet filter rules within an expression. When creating a packet filter rule, you can instruct the BIG-IP system to build an expression for you, in which case you need only choose the criteria from predefined lists, or you can write your own expression text, using the syntax of the tcpdump utility. For more information on the tcpdump utility, see the online man page for the tcpdump command.
You can also configure global packet filtering that applies to all packet filter rules that you create. The following sections describe how to use the Configuration utility to set global packet filtering options, as well as create and manage individual packet filters rules.
iRules
You can use iRules to restrict traffic in almost anyway you can think of. You can set an iRule to keep connections from happening when coming from a certain IP address range or to a certain URI path in the HTTP request.