Skapa och testa egna IPS-signaturer på Sophos Firewall

En egen IPS-signatur är lämplig när Sophos inte tillhandahåller någon passande signatur för ett tydligt beskrivet nätverks- eller applikationsmönster. Den kan till exempel identifiera en känd klartextsträng, en ovanlig protokollegenskap eller en exakt kombination av port, riktning och nyttolast.

Signaturen i sig skyddar ännu ingenting. Den måste användas i en IPS-policy, policyn måste vara kopplad till den brandväggsregel som faktiskt matchas och dataströmmen måste vara synlig för IPS. Ett alltför brett mönster kan blockera legitim trafik, medan ett alltför snävt mönster inte ger några träffar.

Testa först en ny signatur i en IPS-pilotregel med Action: Allow packet. Även om Recommended action redan är Allow packet är det åtgärden i IPS-policyregeln som avgör. Drop packet, Drop session, Reset eller Bypass session påverkar produktionstrafiken och ska inte tas i drift förrän efter reproducerbara positiva och negativa tester.

Sex steg till ett kontrollerat pilottest

1. Beskriv det som ska identifieras med protokoll, riktning, port och ett entydigt mönster.
2. Skapa en signatur under Intrusion prevention > Custom IPS signatures med en snävt avgränsad regel och Recommended action: Allow packet.
3. Lägg till signaturen i en egen regel i en IPS-policy som kan tas bort och välj Action: Allow packet där.
4. Tilldela denna IPS-policy endast till den avsedda pilotbrandväggsregeln och aktivera Log firewall traffic där.
5. Generera ett matchande och ett avsiktligt icke-matchande test och jämför Log Viewer, ips.log och regelmatchningen.
6. Ändra inte åtgärden i IPS-policyregeln förrän godkännandet är stabilt; återställ den tidigare policytilldelningen vid oväntade träffar.

En sparad post eller en godkänd syntaxkontroll bevisar ännu inte att funktionen fungerar. Ett lyckat resultat innebär att det positiva testet matchar exakt den förväntade anpassade signaturen och brandväggsregeln, att det negativa testet inte ger några träffar och att produktionsapplikationen fungerar oförändrat.

När en egen signatur passar

Anpassade signaturer lämpar sig för en stabil egenskap som är synlig på paket- eller strömnivå. Det kan vara ett proprietärt protokollvärde, en tydlig exploitindikator eller ett tillfälligt skydd för en internt känd sårbarhet. Den förväntade datavägen och den önskade reaktionen måste vara fastställda innan signaturen skrivs.

För föränderliga IP-adresser eller domäner passar oftast värdar, tjänster och grupper, hotflöden eller snävt avgränsade brandväggsregler bättre. En anpassad signatur ersätter dessutom varken patchhantering eller en väl utformad regel från tillverkaren. För en enstaka loggträff är en permanent egenutvecklad lösning sällan proportionerlig.

Krypterad nyttolast är en viktig begränsning. IPS kan bara identifiera ett content-mönster i HTTPS-nyttolasten om innehållet faktiskt dekrypteras i den valda bearbetningsvägen och är synligt för motorn. Utan lämplig TLS-inspektion återstår normalt bara okrypterade eller på annat sätt synliga egenskaper.

Kontrollera licens och livscykel i förväg

För att aktivera IPS krävs en aktiv Network Protection-prenumeration eller en giltig provlicens samt administratörsåtkomst för signatur, policy och brandväggsregel. Före pilottestet dokumenteras den befintliga policytilldelningen, regel-ID:t och en säkerhetskopia för återställning. De 30 dagar som nämns nedan börjar när licensen löper ut eller IPS stängs av manuellt, inte först vid nästa konfigurationsförsök.

Egna signaturer kan inte konfigureras om IPS-provlicensen har löpt ut eller om IPS Protection är avstängt under Intrusion prevention > IPS policies. Sophos rekommenderar att IPS aktiveras igen inom 30 dagar om de befintliga anpassade signaturerna ska bevaras. Därför ska en säkerhetskopia eller export ingå i återställningsplanen före licensändringar, IPS-ändringar eller större policyändringar.

Därefter måste IPS vara globalt aktiverat och den brandväggsregel som bearbetar trafiken behöver en IPS-policy. Den fullständiga grundkonfigurationen finns under Konfigurera Sophos Firewall IPS och testa säkert. En anpassad signatur är ett komplement till denna dataväg, inte en parallell skyddsmekanism.

Avgränsa regelsyntaxen på ett begripligt sätt

Dokumentationsbegränsningar för SFOS 22/23: Syntaxhjälpen innehåller exempel med motsägelsefull formatering: distance: 4.within:4; är inte en tillförlitlig mall att kopiera; för byte_jump nämner förklaringstexten jämförelseoperander som saknas i syntaxschemat. Även beteckningarna för reserverade TCP-bitar är oklara. Dessa avsnitt tolkas inte som ytterligare funktioner i motorn. Fragmenten som förklaras nedan förblir dokumentationsexempel, inte regler som har testats på en brandvägg. Om en regel avvisas eller verkar oklar ska exakt build, regel och felmeddelande sparas och frågan utredas med Sophos Support; tillåt ingen blockerande åtgärd i produktion fram till dess.

Inmatningsformuläret skiljer mellan Protocol och Custom rule. I regeln kombineras enskilda nyckelord med sina värden och ett semikolon. Ju fler oberoende egenskaper som måste stämma överens, desto mindre är normalt risken för slumpmässiga träffar. Samtidigt får signaturen inte bli så specifik att en harmlös protokolländring gör den verkningslös.

För ett strikt kontrollerat klartexttest kan TCP användas som protokoll och till exempel följande som ett snävt nyttolastmönster:

content:"AVANET-IPS-PILOT"; nocase;

AVANET-IPS-PILOT är ett avsiktligt iögonfallande dokumentationsvärde. Den tillhörande pilotbrandväggsregeln begränsas dessutom till testtjänsten, exempelvis TCP-port 8080. Token, riktning och port ersätts med värden som förekommer i den verkliga dataströmmen som är synlig för IPS. Detta exempel är inte en universell angreppssignatur och bör inte tillämpas oförändrat på breda produktionsregler.

Nyttolast och sökfönster

content söker efter en tecken- eller bytesekvens; binärvärden anges mellan lodstreck. nocase ignorerar skillnaden mellan stora och små bokstäver vid en innehållsmatchning, medan rawbytes arbetar med rådata. depth och offset begränsar sökningen absolut i nyttolasten, medan distance och within arbetar relativt den föregående träffen. uricontent, isdataat och pcre täcker mer specialiserade URI-, positions- och reguljära uttryck.

Ett snävt sökområde minskar slumpmässiga träffar och beräkningsbehovet. Särskilt pcre, stora fönster eller flera breda innehållsmönster bör endast införas med realistiska paket och under övervakad belastning. Om depth är mindre än det innehållsmönster som söks kan signaturen aldrig ge en träff.

Modifierarna nocase, rawbytes, depth, offset, distance och within hör till content; de är inte självständiga detekteringsregler. Utan depth löper sökningen från offset till nyttolastens slut. Utan within förblir även sökningen efter ett andra innehållsmönster från distance öppen till slutet. Därför räcker inte en startpunkt i sig för att hålla sökfönstret snävt. uricontent söker i den normaliserade begärans-URI:n, inte i godtycklig nyttolast. isdataat kontrollerar om data finns på en angiven position; med relative mäts denna position från slutet av den föregående innehållsträffen.

Header, ström och strukturerade värden

Källa, destination och port kan avgränsas med srcaddr, dstaddr, srcport och dstport. För IP-header finns bland annat ttl, tos, id, ipopts, fragoffset, fragbits, dsize, ip_proto och samip. TCP-egenskaper beskrivs med flags, flow, seq, ack och window; itype, icode, icmp_id och icmp_seq gäller för ICMP. rpc, byte_test och byte_jump är avsedda för strukturerade eller binära protokoll.

flow gäller endast för TCP. Där är to_server och from_client likvärdiga, liksom to_client och from_server. bi_direction utökar detekteringen till båda riktningarna; vid bindning till en port måste det negativa testet därför även ta hänsyn till returtrafiken. Valet mellan no_stream och only_stream får inte förväxlas med en kontroll av paketstorleken: dsize kontrollerar storleken på ett pakets nyttolast och matchar inte paket som har satts samman på nytt från en ström. En kombination med only_stream är därför olämplig. Vid en utebliven träff avgör man först om egenskapen ska sökas i det enskilda paketet eller i den återsammansatta strömmen, i stället för att bara ändra storleken eller innehållsmönstret.

För komplexa regler gäller den ovan beskrivna syntaxen för anpassade IPS-signaturer som stöds av SFOS 22. Odokumenterade Snort-nyckelord eller regler som kopierats från andra motorer bör inte användas utan kontroll.

Operander: adress, port, URI och dataposition

Följande fragment hör hemma i Custom rule, inte i skalet. De är en referens för SFOS 22/23, inte färdigtestade angreppssignaturer. Endast villkor som passar det som ska identifieras kombineras; Protocol, pilotpolicyn och Allow packet förblir en del av testet som beskrivs ovan. Hakparenteser i syntaxmönster markerar valfria delar och ska inte matas in.

• srcaddr:192.0.2.10; dstaddr:198.51.100.20; jämför käll- och destinations-IP med enskilda adresser. Dokumentationsadresserna ersätts med de observerade testadresserna; detta innebär inte att stöd för subnät eller adresslistor kan förutsättas.

• srcport:40000; dstport:8080; jämför käll- och destinationsport med tal. Destinationsporten avser här testtjänsten. En varierande källport på klienten bör bara anges som ett fast värde om den verkligen ingår i det som ska identifieras; annars uppfyller nya anslutningar inte detta villkor.

• uricontent:"/ips-pilot"; söker efter den utbytbara sökvägen i den normaliserade begärans-URI:n. Även blandade text-/binärmönster är möjliga. Jämförelsen måste stämma med det normaliserade URI-värdet, inte bara med hur det skrivs i webbläsarens adressfält.

• content:"AVANET-IPS-PILOT"; isdataat:50,relative; kräver dessutom data på position 50 relativt slutet på denna innehållsträff. Utan relative är positionen absolut i nyttolasten. Talet väljs utifrån protokollets faktiska struktur; det kontrollerar att data finns, inte innehållet i dessa data.

• content:"ABC"; content:"DEF"; distance:1; within:10; använder två utbytbara mönster med ett relativt sökfönster. distance anger avståndet från slutet på den första träffen, medan within begränsar den följande sökningen. För absoluta fönster får även offset och depth numeriska värden, exempelvis offset:4; depth:20; vid tillhörande content. Dessa tal väljs utifrån mönstrets faktiska läge och längd; de är inte standardvärden för protokollet.

Reguljära uttryck med pcre

Grundformerna är pcre:"/REGEX/"; och pcre:"m/REGEX/";. Ett ! före det inledande citattecknet negerar uttrycket, exempelvis pcre:!"/AVANET-IPS-PILOT/i";. Detta är ett villkor för utebliven matchning och kan få mycket bred verkan utan ytterligare avgränsning. REGEX respektive pilottestets token ersätts med det mönster som behövs. Alternativ anges efter det avslutande /, till exempel pcre:"/AVANET-IPS-PILOT/i";.

• i ignorerar skillnaden mellan stora och små bokstäver; s gör att . även matchar radbrytningar.
• m gör att ^ och $ dessutom matchar radbörjan och radslut i bufferten. x ignorerar oskyddade blanktecken i mönstret, utom i teckenklasser.
• A förankrar träffen vid buffertens början. E binder $ endast till det faktiska slutet, inte till positionen före en avslutande radbrytning.
• G vänder kvantifierarnas standardmässiga girighet; ett efterföljande ? vänder den igen.
• R börjar relativt slutet på den senaste mönsterträffen. U använder avkodade URI-buffertar, medan B inte använder avkodade buffertar.

Därför fastställs före pilottestet i vilken buffert och från vilken position mönstret ska gälla. Ett korrekt reguljärt uttryck för rådata behöver inte matcha en avkodad URI.

Läsa binärfält: byte_test och byte_jump

byte_test läser ett fält och kontrollerar dess numeriska värde. Schemat är byte_test:COUNT,[!]OPERATOR,VALUE,OFFSET[,relative][,big|little][,NUMBER_TYPE,string];. COUNT är antalet lästa byte och OFFSET startpunkten i nyttolasten; med relative ligger startpunkten relativt den senaste mönsterträffen. VALUE är jämförelsevärdet. Dokumenterade operatorer är <, >, =, ! och &: mindre än, större än, lika med, inte lika med respektive bitvis OCH. Ett ! före en jämförelseoperator negerar dess resultat. big eller little anger byteordningen. Med string läses textsiffror i stället för ett binärt talfält; hex, dec och oct gäller endast för detta textläge.

Exempel på ett binärfält: byte_test:2,=,16,0,big; läser två byte från nyttolastposition 0 som big-endian och jämför med 16. Antal, position, byteordning och jämförelsevärde måste hämtas från protokollet, inte från detta exempel. Ett slumpmässigt numeriskt värde är inget bevis på ett angrepp.

byte_jump läser däremot en längd och flyttar positionen för efterföljande kontroller. Schemat är byte_jump:COUNT,OFFSET[,relative][,multiplier FACTOR][,big|little][,string][,hex|dec|oct][,align][,from_beginning];. De två första operanderna bestämmer fältbredd och läsposition; relative gör offseten relativ till den senaste mönsterträffen. multiplier multiplicerar det lästa värdet för hopplängden. align avrundar denna uppåt till nästa 32-bitarsgräns. Med from_beginning tillämpas hopplängden från nyttolastens början i stället för från den aktuella positionen. string och talbaserna har samma syfte som för byte_test.

byte_jump:2,0,big; är alltså ett fragment för ett två byte långt längdfält i början av nyttolasten med uttryckligen vald byteordning. Det är ingen storleksjämförelse; jämförelseoperator och jämförelsevärde är inte operander för byte_jump. För båda byte-nyckelorden väljs big eller little uttryckligen vid binära flerbytefält: man bör inte förlita sig på en standardbyteordning som härletts ur dokumentationen. Kontrollera först fält och hoppmål i den verkliga testnyttolasten och testa därefter ett positivt och ett negativt fall för det efterföljande villkoret. En felaktig längd kan flytta sökpositionen förbi det önskade mönstret.

IP-fält, alternativ och fragment

• ttl:64;, ttl:>64; och ttl:<64; jämför IP Time to Live exakt, med större än eller med mindre än. tos:16; jämför TOS-fältet och id:1234; IP-ID-fältet. Dessa exempeltal är inte rekommenderade detekteringsvärden; de väljs utifrån den headeregenskap som faktiskt söks.
• ipopts:rr; kontrollerar en befintlig IP-option. Tillåtna värden är rr (Record Route), eol (End of List), nop (No Operation), ts (Timestamp), sec (Security), lsrr (Loose Source Routing), ssrr (Strict Source Routing), satid (Stream Identifier) och any (valfri IP-option). any kräver alltså en option, inte bara ett godtyckligt IP-paket.
• fragoffset:0; jämför fragmentoffseten i IP-headern med ett decimaltal. Fältet är inte sökoffseten för innehåll i nyttolasten.
• fragbits kontrollerar M (More Fragments), D (Don’t Fragment) och R (Reserved). Ett inledande + tillåter ytterligare bitar utöver de angivna, * kräver minst en av de angivna bitarna och ! kräver att de angivna bitarna inte är satta. Därmed kontrollerar fragbits:+M; att More Fragments är satt utan att utesluta andra bitar.
• dsize:300;, dsize:>300;, dsize:<300; och dsize:300<>400; beskriver exakt nyttolaststorlek, jämförelse med större än/mindre än eller ett intervall. Talen avser paketets nyttolast, inte hela anslutningen. Begränsningarna gentemot rekonstruerade strömmar som förklaras ovan gäller fortfarande.
• ip_proto:6;, ip_proto:!6;, ip_proto:>6; och ip_proto:<6; jämför den numeriska protokollidentifieraren i IP-headern, inte TCP-/UDP-porten. samip; saknar värde och kräver samma käll- och destinations-IP.

TCP-fält och val av ström

flags kontrollerar TCP-flaggor: S för SYN, A för ACK, F för FIN, R för RST, U för URG och P för PSH. Utan modifierare kontrollerar exempelvis flags:S; att exakt SYN är satt. Ett inledande +, * eller ! har den betydelse som förklaras ovan för fragbits. flags:+S; tillåter därför ytterligare flaggor. Hjälpen visar en valfri andra flagggrupp efter ett komma, men förklarar inte dess jämförelsesemantik. Behandla därför inte flags:S,A; som en bekräftad instruktion för att ignorera ACK; låt detta beteende klarläggas för den installerade builden före användning. Specialfall för reserverade TCP-bitar och ”inga flaggor satta” anges här avsiktligt inte som syntax som kan kopieras; de kräver en versionsspecifikt bekräftad regel och får inte härledas ur en oklar beteckning.

För flow finns de redan förklarade riktningarna samt established, no_stream och only_stream. flow:established; kräver en etablerad TCP-anslutning. flow:no_stream; utesluter rekonstruerade strömpaket, medan flow:only_stream; begränsar detekteringen till dessa. Fragmenten förklarar de enskilda valen och är ingen uppmaning att använda båda strömalternativen tillsammans. bi_direction förblir den ovan beskrivna utökningen till trafik i båda riktningarna.

seq:1234;, ack:1234; och window:4096; jämför TCP-sekvensnummer, kvittensnummer respektive fönsterstorlek med ett tal. Exakta sekvens- eller ACK-värden ändras mellan anslutningar och är bara meningsfulla om just detta värde ingår i det som ska identifieras. TCP-fönstret är inget sökfönster för nyttolast.

ICMP och RPC

itype:8; och icode:0; jämför ICMP-typ och ICMP-kod. Båda stöder även <, > och intervall som itype:3<>5;; typ och kod är olika fält. icmp_id:1234; och icmp_seq:1; jämför ICMP-identifierare och sekvensvärde exakt. Värdena väljs utifrån det önskade ICMP-fallet och likställs inte med TCP-sekvensnummer.

rpc:100000,2,*; kontrollerar applikationsnummer 100000, version 2 och valfri procedur i SUNRPC-CALL-begäranden. Schemat är rpc:APPLICATION,VERSION,PROCEDURE;; * är tillåtet för version och procedur, inte för applikationsnumret. Talen ersätts med den applikation, version och procedur som söks. Ett jokertecken gör inte protokollanalysen överflödig: det lämnar avsiktligt respektive del öppen och breddar därmed detekteringen.

Skapa en signatur och tilldela den till en policy

Under Intrusion prevention > Custom IPS signatures > Add anges Name, Protocol, Custom rule, Severity och Recommended action. Ett namn som PILOT-TCP-8080-AVANET-TOKEN tydliggör syftet och testets avgränsning. Severity beskriver den egna riskbedömningen; det bevisar inte att mönstret är skadligt.

Vid den första körningen lämnas Recommended action på Allow packet. Viktigt: åtgärden i IPS-policyregeln åsidosätter denna rekommendation. Därför måste även pilotregeln använda Allow packet. Övriga åtgärder har betydligt större konsekvenser:

• Drop packet kasserar endast det matchande paketet.
• Drop session avslutar sessionen efter träffen.
• Reset avslutar en TCP-session och skickar en reset till ursprunget.
• Bypass session tillåter trafiken och kontrollerar inte resten av sessionen.

Vid sessionsbaserade åtgärder kontrollerar SFOS bara fram till det första matchande paketet. Innan Allow packet ändras till en sådan åtgärd måste det därför vara bekräftat att just denna första träff avser den avsedda sessionen.

När konfigurationen sparas konfigurerar SFOS om IPS-motorn. Om det finns tillräckligt med ledigt RAM sker detta utan avbrott. Vid lite ledigt RAM kan motorn starta om och orsaka ett kort avbrott. Ändringar ska därför göras under ett övervakat tidsfönster, även när signaturen verkar liten. Efter sparandet kontrolleras IPS-status och ips.log för omstarter eller fel innan pilottestet fortsätter.

Efter denna förkontroll sparas signaturen med Save och posten öppnas igen: Protocol, Custom rule, Severity och Recommended action måste motsvara de planerade värdena. Lämna Firewall Acceleration och PKI Acceleration oförändrade under pilottestet; varje aktivering eller avaktivering startar om IPS och snedvrider jämförelsen. Zonkontroll, Trusted MAC, IP-MAC-par och DoS-undantag är separata mekanismer under DoS- och spoofingskydd, inte egenskaper hos en anpassad signatur.

Därefter följer den ofta förbisedda andra delen: öppna en policy avsedd för pilottestet som kan tas bort under Intrusion prevention > IPS policies, lägg till en regel, välj Custom signature, markera signaturen och placera den specifika regeln ovanför bredare regler. SFOS utvärderar IPS-policyregler uppifrån och ned. Spara policyregeln med Save och spara därefter även den överordnade IPS-policyn med Save. Öppna policyn igen och kontrollera det sparade signaturvalet och åtgärden. Därefter kopplas denna policy under Rules and policies > Firewall rules > [Pilotregel] > Detect and prevent exploits (IPS) till den pilotregel som faktiskt matchas; spara även brandväggsregeln och kontrollera med en ny session.

Hantera samma signaturobjekt via XML API

Den som automatiserar pilottestet arbetar med XML-objektet IPSCustomSignature, inte med en IPS-policyregel. Referensen för SFOS 22/23 benämner operationerna Add Custom Signature, Update custom signature och Delete Custom Signature. Åtkomst, explicit skrivoperation, säkerhetskopia, svarsutvärdering och stopp vid oklar nyttolast förklaras centralt i Använd XML API säkert. Innan något skrivs måste objektdefinition och operation bekräftas i API help för den installerade builden; här anges ingen ytterligare körbar skrivbegäran.

I objektexemplet finns Name, Protocol, CustomRule, Severity och RecommendedAction inuti IPSCustomSignature. Name betecknar signaturen, inte policyn eller brandväggsregeln. Parametertabellen kräver en skalär sträng med högst 15 tecken för detta; även Delete kräver detta exakta namn. Välj därför ett kort, entydigt namn som IPS-PILOT-8080 för API-automatisering. Det längre WebAdmin-exempelnamnet ovan är ingen mall att kopiera för API:t. Läs före Update eller Delete den faktiskt sparade identiteten och alla policyanvändningar, i stället för att dra slutsatser om målobjektet från ett SID eller en post med liknande namn.

Tabellen anger alla fem uppgifter för Add/Update som obligatoriska och skalära. Protocol tillåter TCP, UDP, ICMP eller ALL; Severity tillåter Critical, Major, Moderate, Minor eller Warning. CustomRule innehåller signaturdefinitionen som en sträng. Tabellbeteckningen Custom Rule med mellanslag är inte XML-skrivsättet CustomRule. Den ytterligare anvisningen om att skilja bokstäver åt med en punkt förklarar varken någon generell regelkonvertering eller XML-escaping. Ändra därför inte den ovan beskrivna syntaxen mekaniskt med punkter, utan kontrollera regelinnehållet och korrekt XML-kodning för builden. Tillverkarens exempel använder endast SignatureDefinition som platshållare; detta ger ingen färdig signatur som kan tas i drift eller som bevisligen identifierar skadlig trafik.

Blanda inte ihop rekommendation och åtgärd: XML-exemplet skriver RecommendedAction, medan parametertabellen benämner samma ämnesområde Action. Som textvärden anger den Allow Packet, Drop Packet, Drop Session, Reset och Bypass Session samt dessutom 3. Detta är inget bekräftat godkännande för att ersätta RecommendedAction med en XML-tagg Action. För 3 förklaras varken någon betydelse eller koppling till en textåtgärd; gissa inte detta värde och använd det inte heller som förkortning för någon viss åtgärd. Läs tillbaka den faktiskt sparade rekommendationen och fortsätt att kontrollera åtgärden i IPS-policyregeln separat. Ett skapat API-objekt ersätter varken policytilldelning eller positiva och negativa tester.

Stäm av API-svar mot operation och sparat tillstånd

Följande rader är dokumenterade i objektreferenserna för SFOS 22/23. Message.*-namnen förblir dokumentationssymboler vars innebörd inte har klarlagts: de är varken garanterade meddelanden vid körning, översatta feltexter eller slutgiltigt bekräftade orsaker. Även talen är XML-statuskoder, inte HTTP-statuskoder. Spara operation, kod och faktiskt svar tillsammans; ersätt inte de objektspecifika raderna med en generell kodtolkning från den centrala API-artikeln.

För Add Custom Signature anger referensen:

• 200 — Message.CustomSigAddSuccess
• 500 — Message.CustomSigAddFailed
• 502 — Message.CustomSigRecordExists
• 504 — Message.CustomSigInvalidSignatureRule
• 505 — Message.IPSpolicyEngineRestartFail
• 506 — Message.CustomSignatureIpsOff

För Update custom signature anger den:

• 200 — Message.CustomSigUpdateSuccess
• 500 — Message.CustomSigUpdateFailed
• 502 — Message.CustomSigRecordExists
• 504 — Message.CustomSigCustomSignatureCheck1
• 505 — Message.IPSpolicyEngineRestartFail
• 506 — Message.CustomSignatureIpsOff

Just 504 skiljer Add från Update genom symbolen; Message.CustomSigCustomSignatureCheck1 omtolkas inte till ett förmodat entydigt syntaxfelmeddelande. Före ett nytt Add/Update ska posten öppnas igen i WebAdmin eller kontrolleras med en läsfråga som är bekräftad för builden: stämmer Name, Protocol, Custom rule, Severity och Recommended action med det önskade tillståndet? Vid 502 jämförs befintlig och önskad identitet; skriv inte över automatiskt och skapa inte heller en post under ett andra namn. Vid 504 ska dessutom den exakta regeln stämmas av mot buildens dokumentation. Vid 505 kontrolleras det sparade tillståndet, IPS-status och ips.log tillsammans; symbolen innebär varken att en säker återställning har skett eller att motorn får startas om. Vid 506 kontrolleras IPS- och licenstillståndet enligt livscykelavsnittet, men IPS ska inte växlas på ren misstanke. Även efter 200 måste sparade värden, policykoppling och dataväg kontrolleras; 500 bevisar inte att inga partiella ändringar har skett.

För Delete Custom Signature är dessa separata rader dokumenterade:

• 200 — Message.CustomSigDeleteSuccess
• 500 — Message.CustomSigDeleteFailed
• 503 — Message.CustomSignatureInUse
• 506 — Message.CustomSignatureIpsOff

Tillåt Delete först efter den återställning som beskrivs nedan och en fullständig kontroll av användningen. Vid 503 undersöks policyreferenserna till det faktiska objektet; ta inte bort en produktionspolicy utan närmare bedömning. Vid 506 ska IPS- och licenstillståndet klarläggas i stället för att IPS stängs av globalt för ett raderingsförsök. Efter svaret ska det kontrolleras att det exakta namnet inte längre finns och att de beroende policyerna har förväntat tillstånd; vid 500 eller ett oklart svar ska raderingen inte upprepas blint. Om sparat tillstånd, svar eller ansvarsfördelning förblir oklara ska automatiseringen stoppas och det rensade svaret, regelversionen, builden och loggarna gås igenom med Sophos Support. Här hävdas inte att något beteende vid körning har testats på en brandvägg.

Genomför positiva och negativa tester

Det positiva testet skickar det överenskomna mönstret via den avsedda porten och i den förväntade riktningen. I Log Viewer, uppe till höger i WebAdmin, väljs IPS-modulen och filtrering görs efter testtid, Source och Destination. Signatur respektive SID, åtgärd och tidpunkt måste stämma med testet. ips.log ger kompletterande detaljer från motorn. Packet Capture under Diagnostics > Packet capture visar dessutom Firewall Rule ID och IPS Policy ID. Kopplingen mellan regel, Packet Capture och säkerhetsmodul förklaras i Testa brandväggsregler systematiskt.

Efter pilotfasen kan effekten dessutom utvärderas under Reports > Network & threats > Intrusion attacks. Rapporten är användbar för jämförelser mellan tidsperioder, men ersätter inte positiva och negativa tester nära i tid i Log Viewer. XGS 87/87w och XGS 88/88w stöder inte lokal rapportering på enheten; använd de beskrivna direkta kontrollerna i Log Viewer på dessa modeller.

Därefter följer minst ett negativt test: samma tjänst utan token, en annan port eller en avvikande riktning. Signaturen får då inte ge någon träff. Vid ett innehållsmönster är även normala begäranden från applikationen viktiga, eftersom korta eller allmänna strängar kan förekomma i helt legitim nyttolast.

Först när båda testerna är stabila ställs den planerade blockeringsåtgärden in och kontrolleras på nytt. En blockerande signatur är godkänd endast om just det positiva fallet stoppas, det negativa fallet fortsätter och ingen annan brandväggs- eller IPS-regel orsakar effekten.

Kontrollera antalet signaturer

Antalet kan fastställas i WebAdmin utan skalåtkomst. Under Intrusion prevention > IPS policies öppnas en policy som kan tas bort och en ny policyregel skapas. Med Select all visar SFOS det totala antalet ovanför Action. Listan är endast synlig när en regel läggs till i en policy som kan tas bort; dialogrutan kan därefter stängas utan att spara.

Sophos dokumenterar dessutom två läsfrågor under 5. Device management > 3. Advanced shell:

psql -U nobody -d signature -p 5434 -c "select count (*) from tblidprules;"
psql -U nobody -d corporate -c "select count (*) from tblidpcustomsignature;"

Det första kommandot räknar standardsignaturerna och det andra de anpassade signaturerna. Dessa databasfrågor ändrar ingenting, men ska ingå i en dokumenterad support- eller diagnostiksession. Antalet bevisar varken kvalitet eller funktion och kan ändras med mönsteruppdateringar.

För varje fråga förväntas en enda resultatrad under count, följd av (1 row). Sophos exempelvärden 28623 och 1 kommer från ett exempel för SFOS 19.0.1 och är inte målvärden för SFOS 22/23. Ändra inga tabeller eller tjänster vid databas-, anslutnings- eller behörighetsfel: använd kontrollen i WebAdmin och spara exakt utdata samt build för supporten.

Om signaturen inte fungerar som förväntat

Inga träffar

Kontrollera först att IPS är aktivt, att trafiken matchar den förväntade brandväggsregeln med rätt IPS-policy och att den anpassade signaturen faktiskt finns i en policyregel som utvärderas. Därefter kontrolleras protokoll, riktning, port, kryptering och den verkliga nyttolasten. En sträng som visas i webbläsaren behöver inte finnas oförändrad i nätverkspaketet.

En snävt filtrerad Packet Capture som visar riktning, port och det innehåll som är synligt vid denna fångstpunkt är till hjälp. Att ett klartextmönster saknas i en krypterad paketfångst bevisar dock inte att det saknas i den dekrypterade IPS-bufferten. Kontrollera därför fångstpunkt, dekryptering och strömrekonstruktion tillsammans. För ett kontrollerat klartexttest måste det faktiskt överförda mönstret kunna verifieras; därefter kontrolleras offset, depth, distance, within, strömtillstånd och policyreglernas ordning.

För många anslutningar matchar

Signaturen lämnas på Allow packet tills Source, Destination, port, riktning eller sökfönster har avgränsats mer. Allmänna ord, korta binärsekvenser och obegränsade reguljära uttryck är typiska orsaker. En bred brandväggsregel gör dessutom effekten svår att kontrollera.

Om brandväggen visar ökad resursanvändning eller en IPS-omstart efter sparandet ska tidpunkt, modell, firmware, lediga resurser och ips.log sparas. Att då upprepade gånger spara olika varianter är inget tillförlitligt test; först ska orsaken och ett underhållsfönster klarläggas.

Återställ säkert

Vid oväntade träffar tas först den anpassade regeln bort från pilotpolicyn eller den tidigare IPS-policyn återställs på brandväggsregeln. Därefter kontrolleras nya sessioner med positiva och negativa tester. Den anpassade signaturen tas inte bort förrän det inte finns någon annan användning för den.

Före radering bör det vara dokumenterat vilken policy, brandväggsregel och applikation som har använt signaturen. Loggar, den testade regelversionen och skälet till återställningen ska ingå i ändringsdokumentationen. Att stänga av IPS globalt eller ta bort hela produktionspolicyn är ingen lämplig återställning för en enskild felaktig signatur.

Vanliga frågor