Globale indstillinger #

HTTP-profilen håndterer indholdsskift på OSI-modellens applikationslag for både HTTP- og HTTPS-protokoller. Denne profil er designet til intelligent at distribuere indgående webtrafik på tværs af flere backend-ressourcer ved at analysere indholdet af indgående anmodninger og træffe routingbeslutninger baseret på parametre såsom URL, cookies, headers og sessionsoplysninger. Ved at bruge disse oplysninger dirigerer den trafik til de relevante serverpuljer.

I øverste højre afsnit har vi 2 indikatorer. handlinger knapper og Status.
Firkantet kasse: Når der klikkes, stopper LSLB-farmen.
Opdater knappen: Når der klikkes på den, genstarter Farmen.
Knappen Afspil: Hvis gården er slukket eller inaktiv, starter den, når der klikkes på den.

Hver af farverne beskrevet nedenfor repræsenterer Status af en given Farm:
Grøn: Betyder, at gården er UP og alle backends kører. Det kan også betyde, at en omdirigering er konfigureret.
Rød: Betyder, at gården er DOWN eller det er ufunktionelt.
Sort: Angiver en KRITISK skade. Opstår normalt, når en farm er OP, men der ikke er nogen tilgængelig backend, eller de kan være i vedligeholdelsestilstand.
Blå: Viser, når der er en PROBLEM. Farmen kan køre, men når mindst én backend er nede.
Orange: Repræsenterer VEDLIGEHOLDELSE. Viser, når farmen kører, men mindst én backend er i vedligeholdelsestilstand.

Disse farvekoder er konsistente i hele den grafiske brugergrænseflade. For en kortfattet forklaring henvises til LSLB Gårdsektion.

I HTTP(S) farms-profilen, HTTP-headeren X-Forwarded-For udfyldes automatisk med klientens IP-adresse.

Som en omvendt proxy administrerer hver HTTP(S)-farm (eller virtuel tjeneste) flere tjenester. Dette betyder, at én virtuel HTTP-IP og et portpar kan håndtere mere end én belastningsbalanceret webtjeneste. Derfor er der inden for HTTP-farmen en service sektion, der tilbyder virtuel værtsfleksibilitet og tillader oprettelse af backend-lister for hver tjeneste.

Hver HTTP(S)-tjeneste bruger regulære udtryk (for virtuel vært og URL-mønster) i PCRE for at identificere specifikke mønstre i HTTP-headerne på indgående forbindelser. Hvis et mønster matcher i begge virtuel vært og URL-mønster felter, vil backends for den pågældende tjeneste behandle disse indgående forbindelser.

Grundlæggende konfiguration #

Følgende er de grundlæggende parametre for HTTP/S-farmprofilen.

Navn. Dette er et navn, der let identificerer en gård. For at ændre et navn på en given gård, skal du stoppe det først. Sørg for, at et nyt navn ikke allerede er i brug.

Virtuel IP og port. Disse er de virtuelle IP-adresser og portpar, hvorfra farmen vil lytte efter indgående forbindelser. Den nye IP-adresse og portkombination skal være ubrugt og tilgængelig, før den konfigureres.

Lytter. Dette felt specificerer lag 7-protokollen til at udføre indholdsskift.

• HTTP. Den virtuelle tjeneste vil kun modtage almindeligt HTTP-indhold.
• HTTPS. Den virtuelle tjeneste vil modtage sikkert HTTP-indhold, administrere SSL-håndtryk, håndtere sikre chifferkonfigurationer, SSL-certifikater (wildcard eller SNI) osv. for at udføre SSL-offloading. Dette vil fritage de rigtige applikationsservere fra disse tunge opgaver.

HTTPS-parametre #

HTTPS-parametre Kan findes nedenfor.

Deaktiver SSLv2, Deaktiver SSLv3, Deaktiver TLSv1, Deaktiver TLSv1.1, Deaktiver TLSv1.2. Hver af disse skifteknapper aktiverer eller deaktiverer den tilknyttede SSL- eller TLS-version. Det anbefales ikke at deaktivere nogen af ​​protokollerne, da dets tilknyttede cifre også vil blive deaktiveret. TLSv1.3 er aktiveret som standard.

ciphers. Dette afsnit er, hvor vi opbygger lister over ciphers, som vi bruger til at styrke en SSL-forbindelse. Før en klient og server begynder at udveksle oplysninger, der er beskyttet af TLS-protokollen, skal de sikkert udveksle eller aftale en krypteringsnøgle og en krypteringskode, der skal bruges ved kryptering af data.

For at konfigurere en chiffer til brug skal du vælge en af ​​følgende muligheder.

• Alle. Med denne kommando valgt, vil den lyttende HTTP(S)-farm administrere alle de tilgængelige krypteringspakker. Dette er standardindstillingen.
• høj sikkerhed. Denne kommando aktiverer følgende cifre:

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

Aktivering af denne mulighed giver sikkerhed stærk nok til at bestå med en A+ karakter i SSL Labs .

• Brugerdefineret sikkerhed. Denne kommando lader dig tilpasse dine egne cifre gennem Brugerdefinerede chiffere felt.
• Brugerdefinerede cifre. Denne kommando lader dig tilpasse specifikke cifre til at tillade eller forbyde, når du laver en SSL-forbindelse. Det skal være en streng i samme format som i OpenSSL-cifre . Denne kommando vil blive vist hvis Brugerdefineret sikkerhed er indstillet.
• AES SSL HW Offloading. Denne mulighed gør det muligt at aflæse AES-cifre via hardware, hvis processoren tillader aes flag. Dette vil gøre det muligt at optimere ydeevnen af ​​SSL-krypterings-/dekrypteringsopgaven. Test om denne mulighed er kompatibel med din nuværende CPU ved at køre følgende kommando. Hvis CPU-flaggene vises, kan det bruges.

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

Tilgængelige certifikater: Dette er de SSL-certifikater, der er installeret på enheden. For at aktivere et certifikat skal du vælge det og klikke på pileknappen eller trække og slippe det fra boksen Tilgængelig til boksen Aktiveret. Du kan også aktivere/deaktivere flere certifikater eller dem alle.

Aktiverede certifikater: Denne liste viser de certifikater, der i øjeblikket er i brug af gården. Du kan flytte dem til toppen eller bunden ved hjælp af de dobbelte op/ned-pile eller deaktivere dem alle. Bemærk rækkefølgen af ​​certifikaterne; hvis et wildcard-certifikat placeres før et værtscertifikat, vil jokertegnet blive brugt først.

Avancerede indstillinger #

Omskriv placeringsoverskrifter. Hvis aktiveret, er gården tvunget til at ændre Location og Content-location headers som svar på klienterne. Hvis de har værdien af ​​selve backend eller VIP, men med en anden protokol, vil svaret blive ændret til at vise den virtuelle vært i anmodningen. Hvis til/fra-knappen, aktiveret og sammenligne backends er aktiveret, vil kun backend-IP-adressen blive sammenlignet. Dette er vigtigt for at omdirigere en anmodning til en HTTPS-lytter på den samme server som HTTP-lytteren. Hvis dette felt er konfigureret i serviceafsnittet, vil dette direktiv blive ignoreret for den service.

HTTP verber accepteret: Dette felt angiver de HTTP-metoder, der vil blive brugt til at validere HTTP-klientanmodninger. Hvis en klients anmodning bruger en ikke-understøttet metode, vil der blive vist en fejlmeddelelse. Hvert verbum omfatter også yderligere metoder på lavere niveau.

• Standard HTTP-anmodning. Standard HTTP-anmodninger (GET, POST, HEAD).
• + udvidet HTTP-anmodning. udvidede HTTP-anmodninger (PUT, DELETE).
• + muligheder HTTP verbum. udvidede HTTP-anmodninger (PUT, DELETE).
• + standard WebDAV verber. standard WebDAV-verber (LOCK, UNLOCK, PROPFIND, PROPPATCH, SEARCH, MKCOL, MOVE, COPY, Options, TRACE, MKACTIVITY, CHECKOUT, MERGE, RAPPORT).
• + MS-udvidelser WebDAV-verber. MS-udvidelser WebDAV-verber (ABONNER, AFSKRIFT, MEDDEL, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY, BDELETE, CONNECT).
• + MS RPC extensions verber. MS RPC-udvidelsesverber (RPC_IN_DATA, RPC_OUT_DATA).

Ignorer 100 Fortsæt: Hvis aktiveret, vil 100 Fortsæt funktion vil blive deaktiveret. Ifølge HTTP 1.1-protokollen signalerer denne header, at formulardataene ikke skal sendes med den indledende anmodning. I stedet sender den headeren til webserverens backend, som svarer med 100 (Fortsæt). Dette indikerer, at serveren har modtaget anmodningshovederne, og klienten skal fortsætte med at sende anmodningsteksten (f.eks. i en POST-anmodning). Denne funktion er designet til at forhindre ineffektiv datatransmission ved at sikre, at serveren kontrollerer, om anmodningen kan accepteres baseret på overskrifterne alene. Kunder skal sende Forvent: 100-fortsæt som en overskrift og vent på en 100 Fortsæt statuskode, før du fortsætter, eller en 417 Forventning mislykkedes, hvis anmodningen afvises.

Logs: Aktiver eller deaktiver gårdtrafiklogfiler for at fejlsøge og analysere den trafik, der passerer gennem belastningsbalanceren.

Timeout for backend-forbindelse: Denne værdi indstiller den tid, gården vil vente på en forbindelse til backend, normalt ventetiden for socketåbning, i sekunder. Standard er 20 sekunder.

Hyppighed for at kontrollere genopstandne backends: Denne indstilling bestemmer, hvor ofte load balanceren tjekker, om en tidligere sortlistet backend er tilgængelig, og fjerner den fra sortlisten, hvis den er oppe. Farmen tjekker backend med jævne mellemrum, når den er markeret, uanset nye klientforbindelser. Standard er 10 sekunder.

Backend Respons Timeout: Denne værdi indstiller den tid, gården venter på et svar fra backends i sekunder. Standard er 45 sekunder.

Timeout for klientanmodning: Denne værdi indstiller den tid, gården venter på en klients anmodning. Hvis der ikke modtages data inden for denne timeoutperiode, vil forbindelsen blive afbrudt. Standard er 30 sekunder.

HTTP-fejlmeddelelser #

Farm-tjenesten vil vise tilpassede meddelelser på dit websted, når specifikke webkodefejl opdages fra de rigtige servere. Personlige HTML-sider vil blive vist for fejlkoder 414, 500, 501, 503 og WAF 403.

• 414: Request-URI Too Long. Denne fejl opstår, når URI'en overskrider den maksimalt tilladte længde. Hvis du modtager denne fejl, skal du forkorte URL'ens længde.
• 500: Intern serverfejl. Denne fejl indikerer, at backend stødte på en uventet kommando.
• 501: Ikke implementeret. Denne fejl opstår, når anmodningsverbet ikke genkendes eller administreres af proxyen eller backend.
• 503 Service ikke tilgængelig. Denne fejl indikerer, at proxyen ikke kunne finde en tilgængelig backend til anmodningen. Dette kan forekomme, hvis alle backends er nede, eller hvis anmodningens regulære udtryk ikke matcher nogen konfigureret tjeneste.
• WAF 403: Forbudt. Denne fejl opstår, hvis Web Application Firewall (WAF) er aktiveret, og WAF-motoren afviser anmodningen.

Headers #

I denne sektion kan du globalt tilføje eller slette anmodnings- og svarheadere ved at anvende disse handlinger på alle konfigurerede tjenester. Hvis en header er konfigureret i serviceafsnittet, vil den specifikke konfiguration blive tilsidesat.

De handlinger, der skal bruges i dette afsnit, omfatter:

Opret regel. Der oprettes en global overskriftsregel.
Slette. En global overskriftsregel vil blive slettet.

Denne sektion giver dig mulighed for at tilføje eller oprette Header anmodninger og svar, som illustreret på billedet nedenfor.

Type.

• Anmodning: fjern header. Fjerner det angivne headermønster fra klientens HTTP-anmodninger.
• Anmodning: Tilføj overskrift. Tilføjer den angivne header til klientens HTTP-anmodninger.
• Svar: Fjern header. Fjerner det angivne headermønster fra backend HTTP-svar.
• Svar: Tilføj overskrift. Tilføjer den angivne header til backend HTTP-svar.

Header. Angiv den overskrift, der skal tilføjes eller fjernes.
Værdi. Angiv værdien af ​​den givne overskrift, hvis det kræves.

Tjenesteindstillinger #

Tjenesterne inden for en LSLB-farm, der bruger en HTTP-profil, muliggør skift af indhold til virtuelle webtjenester, og konsoliderer flere webapplikationer under samme virtuelle IP og PORT. Denne opsætning letter centraliseret styring af webapplikationer, virtuelle værtskonfigurationer, URL-styring, omdirigeringsopsætningerog persistens og backend-konfigurationer pr. tjeneste. Hver service i en LSLB-farm inkluderer egenskaber til sundhedstjek, persistens, header-styring og en backend-liste. Regulære udtryk kan anvendes for at matche betingelser, der dikterer, hvilken tjeneste der håndterer hver anmodning.

HTTP-farmprofilen evaluerer servicematchbetingelser i prioritetstilstand (kan ændres efter behov). Hvis ingen service matcher, returnerer farmen en HTTP-fejl 503. Derfor understøttes definition af flere tjenester med specifikke betingelser. Anmodninger matcher tjenester baseret på virtuel vært og/eller URL-mønstre.

Det er vigtigt først at oprette og tilføje mindst én backend-server til en tjeneste. Efter anvendelse af den nye tjeneste evalueres HTTP-tjenester sekventielt fra top til bund i listerækkefølgen. Den første tjeneste, der matcher i felterne Vært og/eller URL, behandler den indkommende anmodning baseret på konfigurerede URL- eller værtsmønstre.

De betingelser, der skal matches, er:

Virtual Host. Denne funktion giver dig mulighed for at definere en betingelse baseret på domænenavnet ved at bruge den samme virtuelle IP og port inden for en HTTP-farm. Hvis du vil fjerne denne betingelse, kan du lade feltet stå tomt. Regelmæssige udtryk i PCRE format er understøttet i dette felt.

URL-mønster. Formålet med dette felt er at identificere en webservice baseret på den URL-sti, som klienten anmoder om. URL'en vil blive evalueret i forhold til et udpeget mønster, hvilket sikrer, at dens syntaks er korrekt. Hvis du ønsker at se bort fra denne betingelse, kan du lade feltet stå tomt. Regelmæssige udtryk i PCRE formater understøttes i dette felt, hvilket giver mulighed for avanceret mønstermatchning.

Virtual Host og URL-mønster værdier er regulære udtryk. Hvis den efterlades tom, vil enhver værdi matche. Begge felter skal matche, ellers springer det til næste tjeneste. Det anbefales at bruge mindst én, der fungerer som standard, hvis der ikke er nogen match fundet i bunden.

Planlægger for belastningsbalancering. Dette felt angiver den algoritme, der bruges til at fordele belastningen mellem backend-servere. Den valgte standardalgoritme er vægtbaseret.

• Vægt: forbindelse lineær forsendelse efter vægt. Fordeler forbindelser baseret på tildelte vægte til hver backend. Forespørgsler leveres probabilistisk i henhold til de definerede vægte.
• Mindste respons: dynamisk vægt i henhold til backend-svaret. Justerer backendvægte dynamisk baseret på deres responstider. Hurtigere svar øger sandsynligheden for, at forbindelser dirigeres til disse servere.

Omdiriger #

Hvis tjenesten har omdirigeringsindstillingen aktiveret, bruges backend-servere muligvis ikke, da alle anmodninger vil blive sendt til den angivne URL.

Omdirigeringstype. Der er to typer omdirigeringer:

• Standard: Tager URL'en som en absolut vært og sti at omdirigere til.
• Tilføj: Tilføjer den oprindelige anmodningssti til den angivne vært og sti.

Omdirigeringswebadresse. Angiver, hvor klienten skal omdirigeres efter at have modtaget et svar. Hvis en omdirigeringsværdi er konfigureret, kan du ikke konfigurere backends for denne tjeneste. Når både den virtuelle vært og URL-mønsteret matcher, sender apparatet en HTTP-placeringsoverskrift svar for at omdirigere klienten til den konfigurerede URL.

Omdirigeringskode. Angiver HTTP-statuskoden for omdirigering:

• 301 (flyttet permanent)
• 302 (flyttet midlertidigt)
• 307 (midlertidig omdirigering)

Vedholdenhed #

Denne parameter definerer, hvordan HTTP-tjenesten administrerer klientsessioner og kontrollerer, hvilke HTTP-forbindelser der vedligeholdes for at sikre stabile klientsessioner. Når en type persistenssession er valgt, vil dens Time To Live (TTL) i sekunder blive vist.

Ingen vedholdenhed. Denne indstilling tillader HTTP- eller HTTPS-anmodninger at blive leveret til rigtige servere uden at administrere klientsessioner.
IP: Klientadresse. Denne mulighed bruger klientens IP-adresse til at opretholde åbne klientsessioner på tværs af rigtige servere.
BASIC: Grundlæggende godkendelse. Denne mulighed bruger HTTP-grundlæggende godkendelsesheaderen til at styre klientsessioner. For eksempel, når en webside kræver grundlæggende godkendelse fra klienten, vil en HTTP-header indeholde en streng som følgende:

		HTTP/1.1 401-autorisation påkrævet Server: HTTPd/1.0 Dato: Lør, 27. nov. 2011 10:18:15 GMT
		WWW-Authenticate: Basic realm="Secure Area"
		Indholdstype: tekst/HTML indholdslængde: 31

Så svarer klienten med overskriften:

                FÅ /private/index.html HTTP/1.1 Host: localhost
		Autorisation: Grundlæggende QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Denne grundlæggende autentificeringsstreng bruges som et ID for sessionen for at identificere klientsessionen.
PARM: En URI-parameter. En anden måde at identificere en klientsession på er gennem en URI-parameter adskilt fra et semikolon-tegn, der bruges som brugersession-id. I eksemplet http://www.example.com/private.php;EFD4Y7 parameteren vil blive brugt som sessionsidentifikator.
URL: En anmodningsparameter. Når sessions-id'et sendes gennem en GET-parameter med URL'en, indikerer denne parameter, at det navn, der er knyttet til klientsessions-id'et, vil være muligt. For eksempel en kundeanmodning som http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 skal konfigureres med parameteren Persistens-session-id (sideværdi i dette eksempel) og persistens session time to life (TTL)
Cookie: . Du vil være i stand til at vælge en HTTP-cookievariabel til at læse fra HTTP-headerne og bruge den til at vedligeholde klientsessioner i et givet tidsrum. Det konfigurerede cookienavn i identifikator for persistenssession felt er oprettet af en programmør og indlejret i en webside for at identificere klientsessionen, for eksempel:

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

Derudover bør Persistence session Time To Life (TTL) konfigureres. Denne værdi styrer den tid, som load balanceren sparer, når klienten og backend går uden aktivitet.
HEADER: en anmodningsoverskrift. Et tilpasset HTTP-headerfelt kunne bruges til at identificere klientsessionen. Vedholdenhedssessionen Time To Life og persistenssessions-id'en skal konfigureres. For eksempel:

               GET /index.html HTTP/1.1 Host: www.example.org
               X-sess: 75HRSd4356SDBfrte

Cookie Indsæt #

Hvis den er konfigureret, vil belastningsbalanceren generere en cookie i hvert svar ved hjælp af den relevante backend-nøgle. Dette sikrer, at selvom sessionstabellen ryddes, eller sessioner er deaktiveret, vil den korrekte backend stadig blive valgt. Denne funktion eliminerer behovet for at ændre den rigtige serverkode for at oprette en sessionscookie.

Cookie navn angiver navnet på den cookie, der er oprettet og inkluderet i klientanmodningen eller backend-svaret. Det Cookie sti definerer URI'en eller den relative sti, hvor den nye cookie vil blive etableret. For at anvende cookien på tværs af hele domænet skal du indstille dette felt i overensstemmelse hermed. Det Cookie-domæne angiver det domæne, hvor cookien vil blive sat. Til sidst Cookie TTL angiver antallet af sekunder, cookien forbliver aktiv mellem klienten og backend. Denne værdi skal overstige 0, og den vedrører varigheden uden aktivitet. Når den angivne tid går uden aktivitet, udløber den persistenssession, der er knyttet til cookien.

Gårdværge #

HTTP-farme giver et grundlæggende og indbygget backend-sundhedstjek, men Farmguardian-konfigurationen anbefales til smartere heuristik-backend-sundhedstjek for at sikre, at applikationen er sund.

Nogle indbyggede eller tilpassede avancerede sundhedstjek kan tildeles denne service fra de allerede oprettede farmguardian-checks.

For yderligere Farmguardian information gå til Overvågning > Farmguardian sektion.

Bemærk, at efter valg af gårdværge, vil den automatisk blive anvendt på gården.

HTTPS-backends. Dette afkrydsningsfelt angiver for farmen, at backend-serverne, der er defineret i den aktuelle tjeneste, bruger HTTPS-protokollen, så dataene bliver krypteret, før de sendes.

underliggende programmer #

Vedrørende underliggende programmer, tillader HTTP-farmprofilen konfiguration af følgende egenskaber: Alle backends skal være IPv4 eller IPv6 og med samme IP-version som Farm VIP.

Tilføj backend #

Gennem handlinger menuknappen, er følgende handlinger tilgængelige for en eller flere valgte backends:
Tilføj backend. Denne kommando åbner backend-oprettelsesformularen.
Ovennævnte handlinger: Aktiver vedligeholdelse (Dræn og Klip mode), Deaktiver vedligeholdelse og Slette.

Backend liste #

handlinger. Brug følgende handlinger til at administrere backends:

• Aktiver vedligeholdelse. Brug denne handling, hvis backend tidligere var deaktiveret. At placere en rigtig server i vedligeholdelsestilstand betyder, at ingen nye forbindelser vil blive omdirigeret til den. Der er to metoder til at aktivere vedligeholdelsestilstanden:
  • Dræningstilstand. Bevarer etablerede forbindelser og persistens, hvis aktiveret, men vil ikke tillade nye forbindelser.
  • Cut-tilstand. Dropper alle aktive forbindelser mod backend
• Deaktiver vedligeholdelse. Brug denne handling, når backend er i vedligeholdelsestilstand. Aktiver nye forbindelser til den rigtige server igen efter deaktivering af vedligeholdelsestilstand.
• Slette. Fjern konfigurationer af en valgt virtuel tjeneste. Aliaset vil ikke blive slettet, hvis der er nogen.

Alias. Backend-alias, hvis der er valgt et alias.
IP. IP-adressen på en given backend.
port. Portnummeret på den aktuelle rigtige server.
Timeout. Den tid, det tager en backend at svare. Denne værdi tilsidesætter parameteren for den globale Backend-forbindelsestimeout, men den er begrænset til denne valgte farm.
Vægt. Vægtværdien for den aktuelle rigtige server. Mere vægt indikerer flere forbindelser leveret til den aktuelle backend. Som standard indstilles en vægtværdi på 1. De tilgængelige værdier er fra 1 til 9.
Status. De mulige værdier er:

• Up. Farmen kører, og backend er klar til at modtage forbindelser.
• ned. Farmen kører, og tjenesten har registreret, at backend ikke fungerer
• Vedligeholdelse. Backend er markeret som ikke klar til at modtage forbindelser af administratoren, denne mulighed er nyttig til backends vedligeholdelsesopgaver
• Udefineret. Backend-status er ikke blevet kontrolleret.

Prioritet. Prioritetsværdien for den aktuelle rigtige server. Lavere værdier har mere prioritet. Standardværdien for serviceprioritet er 1. Når en backend fejler, øges serviceprioriteten med 1. Når backend'en er i live igen, reduceres serviceprioritetsværdien med 1. Aktive backends indeholder prioritetsværdier mindre end eller lig med serviceprioriteten .

IPDS-regler for HTTP-farme #

Dette afsnit giver dig mulighed for at aktivere IPDS-regler. Listen viser forskellige typer beskyttelse med et valgfelt for at aktivere dem. For mere information henvises til den specifikke dokumentation for IPDS > Blacklists regler, IPDS > DoS-regler, IPDS > RBL-regler or IPDS > WAF-regler.

For hver af de fire typer IPDS-regler (Blacklist, DoS, WAF og RBL) er der to lister: tilgængelig og Aktiveret. Et kædeikon er også til stede. I den tilgængelig liste, finder du regler af samme type, som kan anvendes på en given bedrift. I den Aktiveret liste, vil du se de regler, der i øjeblikket anvendes på den valgte gård, angivet med deres statussymbol: rød for stoppet og grøn til løb.

Hver regel kan redigeres ved at klikke på redigeringsikonet, som giver dig mulighed for at ændre regelparametre eller starte/stoppe reglen. Bemærk, at nye regler ikke kan oprettes i denne gårdvisning og skal administreres gennem IPDS sektion.

For at tilføje en regel skal du klikke på den ønskede regel og derefter klikke på den enkelte højre pil. Du kan også vælge flere regler ved at holde shift-tasten nede og vælge de ønskede regler, før du klikker på den enkelte højre pil. Klik på højre dobbeltpil for at tilføje alle tilgængelige sortlister.

For at slette en eller flere regler skal du vælge dem og klikke på venstre pil eller klikke på dobbeltpilen for at fjerne alle.