Configurações globais #

O perfil HTTP lida com a troca de conteúdo na camada de aplicação do modelo OSI para os protocolos HTTP e HTTPS. Este perfil foi projetado para distribuir de forma inteligente o tráfego de entrada da Web em vários recursos de back-end, analisando o conteúdo das solicitações recebidas e tomando decisões de roteamento com base em parâmetros como URL, cookies, cabeçalhos e informações de sessão. Usando essas informações, ele direciona o tráfego para os pools de servidores apropriados.

Na seção superior direita, temos 2 Indicadores. Ação botões e os Status.
Caixa quadrada: quando clicado, o farm LSLB será interrompido.
Botão Atualizar: Ao clicar, a Fazenda será reiniciada.
Botão Reproduzir: Se a fazenda estiver desligada ou inativa, ela iniciará ao clicar.

Cada uma das cores descritas abaixo representa o Status de um dado Farm:
Verde: Significa que a fazenda está UP e todos os back-ends estão em execução. Também pode significar que um redirecionamento está configurado.
Vermelho: Significa que a fazenda está BAIXA ou não é funcional.
Preto: Indica um CRÍTICA dano. Geralmente ocorre quando um farm está ATIVADO, mas não há back-end disponível ou pode estar no modo de manutenção.
Azul: Mostra quando há um PROBLEMA. O farm pode estar em execução, mas quando pelo menos um back-end está inativo.
Laranja: Representa MANUTENÇÃO. Mostra quando o farm está em execução, mas pelo menos um back-end está no modo de manutenção.

Esses códigos de cores são consistentes em toda a interface gráfica do usuário. Para uma explicação concisa, consulte o Seção de Fazenda LSLB.

No perfil de farms HTTP (S), o cabeçalho HTTP X-transmitido-Para é preenchido automaticamente com o endereço IP do cliente.

Como um proxy reverso, cada farm HTTP(S) (ou serviço virtual) gerencia vários serviços. Isso significa que um par de IP e porta virtual HTTP pode lidar com mais de um serviço da Web com balanceamento de carga. Portanto, dentro do farm HTTP, existe um serviço seção que oferece flexibilidade de host virtual e permite a criação de listas de backend para cada serviço.

Cada serviço HTTP(S) usa expressões regulares (para host virtual e padrão de URL) no PCRE para identificar padrões específicos nos cabeçalhos HTTP das conexões de entrada. Se um padrão corresponder em ambos os host virtual e Padrão de URL campos, os back-ends desse serviço específico processarão essas conexões de entrada.

Configuração básica #

A seguir estão os parâmetros básicos para o perfil de farm HTTP/S.

Nome. Este é um nome que identifica facilmente uma fazenda. Para alterar o nome de uma determinada fazenda, primeiro você deve interrompê-la. Certifique-se de que um novo nome já não esteja em uso.

IP virtual e porta. Esses são os endereços IP virtuais e os pares de portas dos quais o farm escutará as conexões de entrada. A nova combinação de endereço IP e porta não deve ser usada e deve estar disponível antes de ser configurada.

Ouvinte. Este campo especifica o protocolo da camada 7 para executar a comutação de conteúdo.

• HTTP. O serviço virtual receberá apenas conteúdo HTTP simples.
• HTTPS. O serviço virtual receberá conteúdo HTTP seguro, gerenciará handshakes SSL, lidará com configurações de cifras seguras, certificados SSL (curinga ou SNI), etc., para realizar o descarregamento de SSL. Isso aliviará os servidores de aplicativos reais dessas tarefas pesadas.

Parâmetros HTTPS #

Parâmetros HTTPS pode ser encontrada abaixo.

Desativar SSLv2, Desativar SSLv3, Desativar TLSv1, Desativar TLSv1.1, Desativar TLSv1.2. Cada um desses botões de alternância ativa ou desativa a versão SSL ou TLS associada. Desativar qualquer um dos protocolos não é recomendado, pois suas cifras associadas também serão desativadas. TLSv1.3 está habilitado por padrão.

Cifras. Esta seção é onde construímos listas de cifras que usamos para fortalecer uma conexão SSL. Antes que um cliente e um servidor comecem a trocar informações protegidas pelo protocolo TLS, eles devem trocar ou concordar com segurança sobre uma chave de criptografia e uma cifra para usar ao criptografar dados.

Para configurar uma cifra para uso, selecione uma das seguintes opções.

• Todas as. Com esse comando selecionado, o farm HTTP(S) de escuta gerenciará todos os conjuntos de cifras disponíveis. Esta é a configuração padrão.
• Alta seguranca. Este comando habilita as seguintes cifras:

kEECDH+ECDSA+AES128:kEECDH+ECDSA+AES256:kEECDH+AES128:kEECDH+AES256:kEDH+AES128:kEDH+AES256:DES-CBC3-SHA:+SHA:!aNULL:!eNULL:!LOW:!kECDH:!DSS:!MD5:!EXP:!PSK:!SRP:!CAMELLIA:!SEED

Habilitar esta opção oferece segurança forte o suficiente para passar com um A+ grau em SSL Labs .

• Segurança personalizada. Este comando permite que você personalize suas próprias cifras através do Cifras personalizadas campo.
• Cifras personalizadas. Este comando permite personalizar cifras específicas para permitir ou proibir ao fazer uma conexão SSL. Deve ser uma string no mesmo formato que em Cifras do OpenSSL . Este comando será exibido se Segurança personalizada é definido.
• Descarregamento de HW SSL AES. Esta opção permite que as cifras AES sejam descarregadas via hardware se o processador permitir o Aes bandeira. Isto permitirá otimizar o desempenho da tarefa de criptografia/descriptografia SSL. Teste se esta opção é compatível com sua CPU atual executando o seguinte comando. Se os sinalizadores da CPU forem exibidos, ele poderá ser usado.

root@noid-ee-02:~# grep "flags.* aes" /proc/cpuinfo

Certificados disponíveis: estes são os certificados SSL instalados no dispositivo. Para ativar um certificado, selecione-o e clique no botão de seta ou arraste e solte-o da caixa Disponível para a caixa Ativado. Você também pode ativar/desativar vários certificados ou todos eles.

Certificados habilitados: esta lista mostra os certificados atualmente em uso pelo farm. Você pode movê-los para cima ou para baixo usando as setas duplas para cima/para baixo ou desativar todos eles. Observe a ordem dos certificados; se um certificado curinga for colocado antes de um certificado de host, o curinga será usado primeiro.

Configurações avançadas #

Reescrever cabeçalhos de localização. Se habilitado, o farm é forçado a modificar os cabeçalhos Location e Content-location em resposta aos clientes. Se eles tiverem o valor do próprio backend ou do VIP, mas com um protocolo diferente, a resposta será modificada para mostrar o host virtual na solicitação. Se o botão de alternância, enabled e compare backends estiver habilitado, somente o endereço IP do backend será comparado. Isso é essencial para redirecionar uma solicitação para um listener HTTPS no mesmo servidor que o listener HTTP. Se esse campo for configurado na seção service, essa diretiva será ignorada para esse serviço.

Verbos HTTP aceitos: este campo especifica os métodos HTTP que serão usados ​​para validar solicitações de clientes HTTP. Se a solicitação de um cliente usar um método não suportado, uma mensagem de erro será exibida. Cada verbo também abrange métodos adicionais de nível inferior.

• Pedido HTTP padrão. Solicitações HTTP padrão (GET, POST, HEAD).
• + solicitação HTTP estendida. solicitações HTTP estendidas (PUT, DELETE).
• + opções verbo HTTP. solicitações HTTP estendidas (PUT, DELETE).
• + verbos padrão do WebDAV. verbos padrão do WebDAV (LOCK, UNLOCK, PROPFIND, PROPPATCH, SEARCH, MKCOL, MOVE, COPY, OPÇÕES, TRACE, MKACTIVITY, CHECKOUT, MERGE, REPORT).
• + Verbos extensões Web MSDAV. Verbos WebDAV de extensões MS (SUBSCREVER, UNSUBSCRIBE, NOTIFICAR, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY, BDELETE, CONNECT).
• + Verbos de extensões MS RPC. Verbos de extensões MS RPC (RPC_IN_DATA, RPC_OUT_DATA).

Ignorar 100 Continuar: Se ativado, o 100 Continue recurso será desativado. De acordo com o protocolo HTTP 1.1, este cabeçalho sinaliza que os dados do formulário não devem ser enviados com a solicitação inicial. Em vez disso, ele envia o cabeçalho para o backend do servidor web, que responde com 100 (Continuar). Isso indica que o servidor recebeu os cabeçalhos da solicitação e o cliente deve prosseguir com o envio do corpo da solicitação (por exemplo, em uma solicitação POST). Esse recurso foi projetado para evitar a transmissão ineficiente de dados, garantindo que o servidor verifique se a solicitação pode ser aceita apenas com base nos cabeçalhos. Os clientes devem enviar Espere: 100-continue como cabeçalho e aguarde um código de status 100 Continue antes de prosseguir ou um 417 Expectation Failed se a solicitação for rejeitada.

Logs: habilite ou desabilite os logs de tráfego do farm para depurar e analisar o tráfego que passa pelo balanceador de carga.

Tempo limite de conexão de back-end: esse valor define o tempo que o farm aguardará por uma conexão com o back-end, geralmente o tempo de espera de abertura do soquete, em segundos. O padrão é 20 segundos.

Frequência para verificar back-ends ressuscitados: esta configuração determina com que frequência o balanceador de carga verifica se um back-end anteriormente colocado na lista negra está acessível e o remove da lista negra se estiver ativo. O farm verifica o back-end periodicamente quando ele é reduzido, independentemente de novas conexões de cliente. O padrão é 10 segundos.

Tempo limite de resposta de back-end: esse valor define o tempo que o farm aguardará por uma resposta dos back-ends em segundos. O padrão é 45 segundos.

Tempo limite de solicitação do cliente: esse valor define o tempo que o farm aguardará pela solicitação de um cliente. Se nenhum dado for recebido dentro deste período de tempo limite, a conexão será encerrada. O padrão é 30 segundos.

Mensagens de erro HTTP #

O serviço farm exibirá mensagens personalizadas em seu site quando erros específicos de código da web forem detectados em servidores reais. Páginas HTML personalizadas serão mostradas para os códigos de erro 414, 500, 501, 503 e WAF 403.

• 414: Pedido-URI muito longo. Este erro ocorre quando o URI excede o comprimento máximo permitido. Se você receber esse erro, reduza o comprimento do URL.
• 500: Erro interno do servidor. Este erro indica que o back-end encontrou um comando inesperado.
• 501: Não implementado. Este erro ocorre quando o verbo de solicitação não é reconhecido ou gerenciado pelo proxy ou backend.
• 503 serviço indisponível. Este erro indica que o proxy não conseguiu encontrar um back-end disponível para a solicitação. Isso poderá ocorrer se todos os back-ends estiverem inativos ou se a expressão regular da solicitação não corresponder a nenhum serviço configurado.
• WAF 403: Proibido. Este erro ocorre se o Web Application Firewall (WAF) estiver habilitado e o mecanismo WAF rejeitar a solicitação.

Cabeçalhos #

Nesta seção, você pode adicionar ou excluir globalmente cabeçalhos de solicitação e resposta, aplicando essas ações a todos os serviços configurados. Se um cabeçalho for configurado na seção de serviço, essa configuração específica será substituída.

As ações a serem usadas nesta seção incluem:

Criar regra. Uma regra de cabeçalho global será criada.
Apagar. Uma regra de cabeçalho global será excluída.

Esta seção permite adicionar ou criar cabeçalho solicitações e respostas, conforme ilustrado na imagem abaixo.

Formato.

• Pedido: remover cabeçalho. Remove o padrão de cabeçalho especificado das solicitações HTTP do cliente.
• Pedido: adicionar cabeçalho. Adiciona o cabeçalho especificado às solicitações HTTP do cliente.
• Resposta: remova o cabeçalho. Remove o padrão de cabeçalho especificado das respostas HTTP de back-end.
• Resposta: adicionar cabeçalho. Adiciona o cabeçalho especificado às respostas HTTP de back-end.

cabeçalho. Indique o cabeçalho a ser adicionado ou removido.
Valor. Indique o valor do cabeçalho fornecido, se necessário.

Configurações de serviços #

Os serviços em um farm LSLB usando um perfil HTTP permitem a troca de conteúdo para serviços virtuais da web, consolidando vários aplicativos da web sob o mesmo IP e PORT virtual. Esta configuração facilita gerenciamento centralizado de aplicações web, configurações de host virtual, Gerenciamento de URLs, configurações de redirecionamento e configurações de persistência e back-end por serviço. Cada serviço em um farm LSLB inclui propriedades para verificações de integridade, persistência, gerenciamento de cabeçalho e uma lista de back-end. Expressões regulares podem ser aplicadas para combinar condições que determinam qual serviço trata cada solicitação.

O perfil do farm HTTP avalia as condições de correspondência de serviço no modo de prioridade (modificável conforme necessário). Se nenhum serviço corresponder, o farm retornará um erro HTTP 503. Portanto, há suporte para a definição de vários serviços com condições específicas. As solicitações correspondem a serviços baseados em host virtual e/ou padrões de URL.

É essencial primeiro criar e adicionar pelo menos um servidor backend a um serviço. Depois de aplicar o novo serviço, os serviços HTTP são avaliados sequencialmente de cima para baixo na ordem da lista. O primeiro serviço correspondente nos campos Host e/ou URL processa a solicitação recebida com base no URL configurado ou nos padrões de Host.

As condições que precisam ser atendidas são:

Host Virtual. Esse recurso permite definir uma condição com base no nome de domínio usando o mesmo IP virtual e porta em um farm HTTP. Se quiser remover esta condição, você pode deixar o campo vazio. Expressões regulares em PCRE formato são suportados neste campo.

Padrão de URL. O objetivo deste campo é identificar um serviço web com base no caminho da URL que o cliente está solicitando. A URL será avaliada em relação a um padrão designado, garantindo que sua sintaxe esteja correta. Caso queira desconsiderar esta condição, você pode deixar o campo vazio. Expressões regulares em PCRE formato são suportados neste campo, permitindo correspondência avançada de padrões.

O Host Virtual e Padrão de URL valores são expressões regulares. Se deixado em branco, qualquer valor corresponderá. Ambos os campos devem corresponder ou pulará para o próximo serviço. Recomenda-se usar pelo menos um, servindo como padrão caso não haja correspondência detectada na parte inferior.

Agendador de balanceamento de carga. Este campo especifica o algoritmo usado para distribuir a carga entre os servidores backend. O algoritmo padrão selecionado é baseado em peso.

• Peso: conexão linear de despacho por peso. Distribui conexões com base nos pesos atribuídos a cada back-end. As solicitações são entregues de forma probabilística de acordo com os pesos definidos.
• Menor Resposta: peso dinâmico de acordo com a resposta do backend. Ajusta os pesos de back-end dinamicamente com base nos tempos de resposta. Respostas mais rápidas aumentam a probabilidade de as conexões serem direcionadas para esses servidores.

Redirecionar #

Se o serviço tiver a opção de redirecionamento ativada, os servidores de back-end não poderão ser usados, pois todas as solicitações serão enviadas para o URL especificado.

Tipo de redirecionamento. Existem dois tipos de redirecionamentos:

• Padrão: considera o URL como um host absoluto e um caminho para o qual redirecionar.
• Acrescentar: acrescenta o caminho da solicitação original ao host e ao caminho especificados.

URL de redirecionamento. Especifica para onde o cliente deve ser redirecionado após receber uma resposta. Se um valor de redirecionamento estiver configurado, você não poderá configurar back-ends para esse serviço. Quando o host virtual e o padrão de URL corresponderem, o dispositivo enviará uma mensagem Cabeçalho de localização HTTP resposta para redirecionar o cliente para o URL configurado.

Código de redirecionamento. Especifica o código de status HTTP para redirecionamento:

• 301 mudou-se permanentemente)
• 302 (movido temporariamente)
• 307 (redirecionamento temporário)

Persistência #

Este parâmetro define como o serviço HTTP gerencia sessões de cliente e controla quais conexões HTTP são mantidas para garantir sessões de cliente estáveis. Uma vez selecionado um tipo de sessão de persistência, seu Time To Live (TTL) em segundos será exibido.

Sem persistência. Esta opção permite que solicitações HTTP ou HTTPS sejam entregues a servidores reais sem gerenciar sessões de cliente.
IP: endereço do cliente. Esta opção utiliza o endereço IP do cliente para manter sessões de cliente abertas em servidores reais.
BASIC: autenticação básica. Esta opção utiliza o cabeçalho de autenticação básica HTTP para controlar as sessões do cliente. Por exemplo, quando uma página da web requer autenticação básica do cliente, um cabeçalho HTTP conterá uma string como a seguinte:

		HTTP/1.1 401 Autorização necessária Servidor: HTTPd/1.0 Data: Sábado, 27 de novembro de 2011 10:18:15 GMT
		WWW-Authenticate: Reino Básico = “Área Segura”
		Tipo de conteúdo: texto/HTML Comprimento do conteúdo: 31

Então o cliente responde com o cabeçalho:

                GET /private/index.html Host HTTP/1.1: localhost
		Autorização: QWxhZGRpbjpvcGVuIHNlc2FtZQ básico==

Essa sequência de autenticação básica é usada como um ID para a sessão para identificar a sessão do cliente.
PARM: um parâmetro de URI. Outra maneira de identificar uma sessão do cliente é por meio de um parâmetro URI separado de um caractere de ponto-e-vírgula usado como um identificador de sessão do usuário. No exemplo http://www.example.com/private.php;EFD4Y7 o parâmetro será usado como o identificador da sessão.
URL: um parâmetro de solicitação. Quando o ID da sessão é enviado através de um parâmetro GET com a URL, este parâmetro indica que o nome associado ao ID da sessão do cliente será possível. Por exemplo, uma solicitação de cliente como http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 deve ser configurado com o parâmetro Identificador de Sessão de Persistência (valor sid neste exemplo) e o tempo de vida útil da sessão de persistência (TTL)
BOLACHA: . Você poderá selecionar uma variável de cookie HTTP para ler os cabeçalhos HTTP e usá-la para manter as sessões do cliente por um determinado tempo. O nome do cookie configurado no identificador de sessão de persistência campo é criado por um programador e inserido em uma página da Web para identificar a sessão do cliente, por exemplo:

                GET /spec.html Host HTTP/1.1: www.example.org
                Cookie: sessionidexample=75HRSd4356SDBfrte

Além disso, a sessão de persistência Time To Life (TTL) deve ser configurada. Este valor gerencia o tempo que o balanceador de carga economiza quando o cliente e o backend ficam sem nenhuma atividade.
HEADER: um cabeçalho de solicitação. Um campo personalizado de cabeçalho HTTP pode ser usado para identificar a sessão do cliente. É necessário configurar o Time To Life da sessão de persistência e o identificador de sessão de persistência. Por exemplo:

               GET /index.html Host HTTP/1.1: www.example.org
               Sessão X: 75HRSd4356SDBfrte

Inserção de cookie #

Se configurado, o balanceador de carga gerará um biscoito em cada resposta usando a chave de back-end apropriada. Isso garante que mesmo que a tabela de sessões seja limpa ou as sessões desativadas, o back-end correto ainda será selecionado. Este recurso elimina a necessidade de modificar o código real do servidor para criar um cookie de sessão.

O Nome do cookie especifica o nome do cookie criado e incluído na solicitação do cliente ou na resposta de back-end. O Caminho do bolinho define o URI ou caminho relativo onde o novo cookie será estabelecido. Para aplicar o cookie em todo o domínio, defina este campo adequadamente. O Domínio do cookie indica o domínio onde o cookie será definido. Por último, o Cookie TTL denota o número de segundos que o cookie permanece ativo entre o cliente e o back-end. Este valor deve exceder 0 e refere-se ao tempo sem qualquer atividade. Depois que o tempo especificado passar sem atividade, a sessão de persistência associada ao cookie expirará.

Farmguardian #

Os farms HTTP fornecem uma verificação de integridade de back-end básica e nativa, mas a configuração do Farmguardian é recomendada para verificações de integridade de back-end heurísticas mais inteligentes para garantir que o aplicativo esteja íntegro.

Algumas verificações de integridade avançadas ou personalizadas podem ser atribuídas a esse serviço a partir das verificações de farmguardians já criadas.

Para mais informações de Farmguardian, vá para o Monitorização> Farmguardian seção.

Observe que depois de selecionar o guardião da fazenda, ele será aplicado automaticamente ao farm.

Back-ends HTTPS. Essa caixa de seleção indica ao farm que os servidores de back-end definidos no serviço atual estão usando o protocolo HTTPS para que os dados sejam criptografados antes de serem enviados.

Backends #

A respeito de Backends, o perfil do farm HTTP permite a configuração das seguintes propriedades: Todos os back-ends devem ser IPv4 ou IPv6 e com a mesma versão de IP do Farm VIP.

Adicionar back-end #

Através de Ação botão de menu, as seguintes ações estão disponíveis para um ou mais back-ends selecionados:
Adicionar back-end. Este comando abre o formulário de criação de back-end.
As ações mencionadas acima: Ativar manutenção (Drenar e Cortar modo), Desativar a manutenção e Apagar.

Lista de back-end #

Ação. Use as seguintes ações para gerenciar os back-ends:

• Ativar manutenção. Use esta ação se o back-end foi desabilitado anteriormente. Colocar um servidor real em modo de manutenção significa que nenhuma nova conexão será redirecionada para ele. Existem dois métodos para ativar o modo de manutenção:
  • Drenar modo. Mantém conexões estabelecidas e persistência, se ativado, mas não admitirá novas conexões.
  • Modo de corte. Solta todas as conexões ativas no backend
• Desativar manutenção. Use esta ação quando o back-end estiver no modo de manutenção. Habilite novas conexões com o servidor real novamente após desabilitar o modo de manutenção.
• Apagar. Remova as configurações de um serviço virtual selecionado. O alias não será excluído se houver algum.

aliás. Alias ​​de back-end, se algum alias foi selecionado.
IP. O endereço IP de um determinado back-end.
Porta. O número da porta do servidor real atual.
Timeout. O tempo que um back-end leva para responder. Esse valor substitui o parâmetro do tempo limite de conexão de back-end global, mas é limitado a este farm selecionado.
Peso. O valor de peso para o servidor real atual. Mais peso indica mais conexões entregues ao back-end atual. Por padrão, um valor de peso de 1 será definido. A faixa de valores disponível é de 1 a 9.
Status. Os valores possíveis são:

• Up. O farm está em execução e o back-end está pronto para receber conexões.
• Para baixo. O farm está em execução e o serviço detectou que o back-end não está funcionando
• Manutenção. O backend está marcado como não pronto para receber conexões pelo administrador, esta opção é útil para tarefas de manutenção do backend
• Indefinido. O status do back-end não foi verificado.

Prioridade. O valor de prioridade para o servidor real atual. Valores mais baixos têm mais prioridade. O valor de prioridade de serviço padrão é 1. Quando um back-end falha, a prioridade do serviço é aumentada em 1. Quando o back-end está ativo novamente, o valor de prioridade do serviço é reduzido em 1. Back-ends ativos contêm valores de prioridade menores ou iguais à prioridade do serviço .

Regras do IPDS para farms HTTP #

Esta seção permite ativar regras IPDS. A lista exibe diferentes tipos de proteção com uma caixa de seleção para ativá-los. Para obter mais informações, consulte a documentação específica para IPDS > Regras de listas negras, IPDS > regras DoS, IPDS > Regras RBL or IPDS > Regras WAF.

Para cada um dos quatro tipos de regras IPDS (lista negra, DoS, WAF e RBL), existem duas listas: Disponível e Os utilizadores da app Smart Spaces com Google Wallet podem usufruir de acesso móvel sem contacto com qualquer leitor HID® Signo™ habilitado com NFC.. Um ícone de corrente também está presente. No Disponível lista, você encontrará regras do mesmo tipo que podem ser aplicadas a um determinado farm. No Os utilizadores da app Smart Spaces com Google Wallet podem usufruir de acesso móvel sem contacto com qualquer leitor HID® Signo™ habilitado com NFC. lista, você verá as regras atualmente aplicadas à fazenda selecionada, indicadas pelo seu símbolo de status: vermelho para parado e verde para correr.

Cada regra pode ser editada clicando no ícone de edição, que permite alterar os parâmetros da regra ou iniciar/interromper a regra. Observe que novas regras não podem ser criadas nesta visualização de farm e devem ser gerenciadas através do IPDS seção.

Para adicionar uma regra, clique na regra desejada e depois clique na seta única para a direita. Você também pode selecionar várias regras mantendo pressionada a tecla Shift e selecionando as regras desejadas antes de clicar na seta única para a direita. Para adicionar todas as listas negras disponíveis, clique na seta dupla para a direita.

Para excluir uma ou mais regras, selecione-as e clique na seta para a esquerda ou clique na seta dupla para remover todas.