Aangepaste IPS-signatures op Sophos Firewall maken en testen

Een eigen IPS-signatuur is zinvol wanneer Sophos geen passende signatuur levert voor een duidelijk beschreven netwerk- of toepassingspatroon. Deze kan bijvoorbeeld een bekende tekststring in platte tekst, een ongebruikelijk protocolkenmerk of een nauwkeurige combinatie van poort, richting en payload herkennen.

De signatuur alleen beschermt nog niets. Deze moet in een IPS Policy worden gebruikt, die policy moet gekoppeld zijn aan de firewallregel waarop het verkeer daadwerkelijk matcht en de gegevensstroom moet zichtbaar zijn voor IPS. Een te breed patroon kan legitiem verkeer blokkeren; een te nauw patroon levert geen matches op.

Test een nieuwe signatuur eerst in een pilot-IPS-regel met Action: Allow packet. Ook als Recommended action al Allow packet is, bepaalt de actie van de IPS-policyregel wat er gebeurt. Drop packet, Drop session, Reset of Bypass session beïnvloeden productieverkeer en mogen pas na een reproduceerbare positieve en negatieve test in productie worden gebruikt.

In zes stappen naar een gecontroleerde pilot

1. Beschrijf de detectie met protocol, richting, poort en een eenduidig patroon.
2. Maak onder Intrusion prevention > Custom IPS signatures een signatuur aan met een nauw afgebakende regel en Recommended action: Allow packet.
3. Voeg de signatuur toe aan een eigen regel in een IPS Policy die verwijderd mag worden en kies daar Action: Allow packet.
4. Wijs deze IPS Policy alleen toe aan de beoogde pilot-firewallregel en schakel daar Log firewall traffic in.
5. Voer zowel een passende als een bewust niet-passende test uit en vergelijk Log Viewer, ips.log en de regelmatch.
6. Wijzig de actie van de IPS-policyregel pas na een stabiele acceptatietest; herstel bij onverwachte matches de eerdere policytoewijzing.

Een opgeslagen item of een geslaagde syntaxiscontrole is nog geen bewijs dat de signatuur werkt. Succes betekent: de positieve test matcht precies de verwachte Custom Signature en firewallregel, de negatieve test levert geen match op en de productietoepassing blijft zich ongewijzigd gedragen.

Wanneer een eigen signatuur geschikt is

Custom Signatures zijn geschikt voor een stabiel kenmerk dat zichtbaar is op pakket- of streamniveau. Dat kan een waarde in een bedrijfseigen protocol zijn, een duidelijke exploitindicator of een tijdelijke bescherming voor een intern bekende kwetsbaarheid. Het verwachte gegevenspad en de gewenste reactie moeten vaststaan voordat de signatuur wordt geschreven.

Voor wisselende IP-adressen of domeinen zijn Hosts, Services en groepen, Threat Feeds of nauw afgebakende firewallregels meestal beter geschikt. Een Custom Signature vervangt bovendien noch patchmanagement, noch een correct opgestelde regel van de fabrikant. Voor een eenmalige logmatch is blijvend eigen ontwikkelwerk zelden proportioneel.

Versleutelde payloads vormen een belangrijke beperking. IPS kan een content-patroon in de HTTPS-payload alleen herkennen als de inhoud in het gekozen verwerkingspad daadwerkelijk wordt ontsleuteld en zichtbaar is voor de engine. Zonder passende TLS Inspection blijven normaal gesproken alleen onversleutelde of anderszins zichtbare kenmerken over.

Controleer vooraf de licentie en levenscyclus

Om IPS in te schakelen is een actief Network Protection-abonnement of een geldige proeflicentie nodig, plus beheerderstoegang voor de signatuur, policy en firewallregel. Leg vóór de pilot de bestaande policytoewijzing, de regel-ID en een back-up voor herstel vast. De hieronder genoemde 30 dagen beginnen bij het verlopen van de licentie of het handmatig uitschakelen van IPS, niet pas bij de volgende configuratiepoging.

Eigen signaturen kunnen niet worden geconfigureerd wanneer de IPS-proeflicentie is verlopen of IPS Protection onder Intrusion prevention > IPS policies is uitgeschakeld. Sophos raadt aan IPS binnen 30 dagen weer in te schakelen als de bestaande Custom Signatures behouden moeten blijven. Een back-up of export hoort daarom vóór wijzigingen aan de licentie, IPS of grotere policywijzigingen in het herstelplan te worden opgenomen.

IPS moet vervolgens globaal actief zijn en de firewallregel die het verkeer verwerkt, moet een IPS Policy hebben. De volledige basisconfiguratie staat onder Sophos Firewall IPS instellen en veilig testen. Een Custom Signature is een aanvulling op dit gegevenspad, geen parallel beschermingsmechanisme.

De regelsyntaxis duidelijk afbakenen

Documentatiebeperkingen voor SFOS 22/23: De syntaxishulp bevat inconsistent opgemaakte voorbeelden: distance: 4.within:4; is geen betrouwbaar voorbeeld om te kopiëren; bij byte_jump noemt de toelichting vergelijkingsoperanden die in het syntaxisschema ontbreken. Ook de labels voor gereserveerde TCP-bits zijn onduidelijk. Deze passages worden niet geïnterpreteerd als extra mogelijkheden van de engine. De hieronder toegelichte fragmenten blijven documentatievoorbeelden, geen regels die op een firewall zijn getest. Bewaar bij een afgewezen of onduidelijke regel de exacte build, de regel en de foutmelding en laat Sophos Support dit uitzoeken; geef tot die tijd geen blokkerende actie vrij voor productie.

Het invoerscherm maakt onderscheid tussen Protocol en Custom rule. In de regel worden afzonderlijke sleutelwoorden gecombineerd met hun waarden en een puntkomma. Hoe meer onafhankelijke kenmerken overeen moeten komen, hoe kleiner normaal gesproken het risico op toevallige matches. Tegelijkertijd mag de signatuur niet zo specifiek worden dat een onschuldige protocolwijziging deze onwerkzaam maakt.

Voor een uitsluitend gecontroleerde test met platte tekst kan TCP als protocol worden gebruikt, met bijvoorbeeld het volgende nauw afgebakende payloadpatroon:

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

AVANET-IPS-PILOT is een bewust opvallende documentatiewaarde. De bijbehorende pilot-firewallregel wordt daarnaast beperkt tot de testdienst, bijvoorbeeld TCP-poort 8080. Token, richting en poort worden vervangen door waarden die voorkomen in de werkelijke gegevensstroom die voor IPS zichtbaar is. Dit voorbeeld is geen universele aanvalssignatuur en mag niet ongewijzigd op brede productieregels worden toegepast.

Payload en zoekvenster

content zoekt een teken- of bytereeks; binaire waarden worden tussen pipe-tekens genoteerd. nocase negeert hoofdletters en kleine letters bij een contentmatch, rawbytes werkt op de ruwe gegevens. depth en offset begrenzen de zoekopdracht absoluut binnen de payload, terwijl distance en within relatief ten opzichte van de vorige match werken. uricontent, isdataat en pcre dekken specifiekere URI-controles, positiecontroles en reguliere expressies af.

Een nauw zoekbereik vermindert toevallige matches en rekenwerk. Vooral pcre, grote vensters of meerdere brede contentpatronen mogen alleen met realistische pakketten en onder gecontroleerde belasting worden ingevoerd. Als depth kleiner is dan het gezochte contentpatroon, kan de signatuur nooit matchen.

De modifiers nocase, rawbytes, depth, offset, distance en within horen bij content; het zijn geen onafhankelijke detectieregels. Zonder depth loopt de zoekopdracht vanaf offset tot het einde van de payload. Zonder within blijft ook de zoekopdracht naar een tweede contentpatroon vanaf distance tot het einde open. Daarom is een beginpunt alleen niet voldoende om het zoekvenster nauw te houden. uricontent doorzoekt de genormaliseerde request-URI, niet willekeurige payloadgegevens. isdataat controleert of op een opgegeven positie gegevens aanwezig zijn; met relative is deze positie relatief ten opzichte van het einde van de vorige contentmatch.

Header, stream en gestructureerde waarden

Bron, bestemming en poort kunnen worden afgebakend met srcaddr, dstaddr, srcport en dstport. Voor IP-headers zijn onder andere ttl, tos, id, ipopts, fragoffset, fragbits, dsize, ip_proto en samip beschikbaar. TCP-kenmerken worden beschreven met flags, flow, seq, ack en window; itype, icode, icmp_id en icmp_seq gelden voor ICMP. rpc, byte_test en byte_jump zijn bedoeld voor gestructureerde of binaire protocollen.

flow geldt alleen voor TCP. Daarbij zijn to_server en from_client gelijkwaardig, net als to_client en from_server. bi_direction breidt de detectie uit naar beide richtingen; bij een poortbinding moet de negatieve test daarom ook rekening houden met het retourverkeer. De keuze tussen no_stream en only_stream mag niet worden verward met een controle van de pakketgrootte: dsize controleert de payloadgrootte van een pakket en matcht niet op pakketten die uit een stream zijn gereconstrueerd. Een combinatie met only_stream is daarom ongeschikt. Bij een ontbrekende match wordt eerst bepaald of het kenmerk in het afzonderlijke pakket of in de gereconstrueerde stream moet worden gezocht, in plaats van alleen de grootte of het contentpatroon te wijzigen.

Voor complexe regels geldt de hierboven beschreven Custom-IPS-syntaxis die door SFOS 22 wordt ondersteund. Niet-gedocumenteerde Snort-sleutelwoorden of regels die uit andere engines zijn gekopieerd, mogen niet zonder controle worden overgenomen.

Operanden: adres, poort, URI en gegevenspositie

De volgende fragmenten horen in Custom rule, niet in de shell. Ze vormen een referentie voor SFOS 22/23, geen volledig geteste aanvalssignaturen. Alleen de voorwaarden die bij de detectie passen, worden gecombineerd; Protocol, de pilot-policy en Allow packet blijven onderdeel van de hierboven beschreven test. Vierkante haken in syntaxisschema’s geven optionele onderdelen aan en worden niet mee ingevoerd.

• srcaddr:192.0.2.10; dstaddr:198.51.100.20; vergelijkt het bron- en bestemmings-IP met afzonderlijke adressen. De documentatieadressen worden vervangen door de waargenomen testadressen; hieruit kan geen ondersteuning voor subnetten of adreslijsten worden afgeleid.

• srcport:40000; dstport:8080; vergelijkt de bron- en bestemmingspoort met getallen. De bestemmingspoort staat hier voor de testdienst. Een wisselende bronpoort van de client moet alleen vast worden opgegeven als die werkelijk onderdeel is van de detectie; anders voldoen nieuwe verbindingen niet aan deze voorwaarde.

• uricontent:"/ips-pilot"; zoekt het te vervangen pad in de genormaliseerde request-URI. Ook gemengde tekst-/binaire patronen zijn mogelijk. De vergelijking moet passen bij de genormaliseerde URI-waarde, niet alleen bij de schrijfwijze in de adresbalk van de browser.

• content:"AVANET-IPS-PILOT"; isdataat:50,relative; vereist daarnaast gegevens op positie 50 ten opzichte van het einde van deze contentmatch. Zonder relative is de positie in de payload absoluut. Het getal wordt gekozen op basis van de werkelijke protocolopbouw; het controleert de beschikbaarheid van gegevens, niet de inhoud ervan.

• content:"ABC"; content:"DEF"; distance:1; within:10; gebruikt twee te vervangen patronen met een relatief zoekvenster. distance legt de afstand vanaf het einde van de eerste match vast, within begrenst de daaropvolgende zoekopdracht. Voor absolute vensters krijgen offset en depth eveneens getalswaarden, bijvoorbeeld offset:4; depth:20; bij de bijbehorende content. Deze getallen worden gekozen op basis van de werkelijke positie en lengte van het patroon; het zijn geen standaardwaarden van het protocol.

Reguliere expressies met pcre

De basisvormen zijn pcre:"/REGEX/"; en pcre:"m/REGEX/";. Een ! vóór het openingsaanhalingsteken keert de matchvoorwaarde van de expressie om, bijvoorbeeld pcre:!"/AVANET-IPS-PILOT/i";. Dit is een voorwaarde voor het ontbreken van een match en kan zonder aanvullende afbakening zeer breed werken. REGEX of het pilottoken wordt vervangen door het benodigde patroon. Opties staan na de afsluitende /, bijvoorbeeld pcre:"/AVANET-IPS-PILOT/i";.

• i negeert hoofdletters en kleine letters; s laat . ook regeleinden matchen.
• m laat ^ en $ ook matchen op het begin en einde van regels in de buffer. x negeert niet-geëscapete witruimtetekens in het patroon, behalve in tekenklassen.
• A verankert de match aan het begin van de buffer. E bindt $ alleen aan het werkelijke einde, niet aan de positie vóór een afsluitend regeleinde.
• G keert de standaard-gretigheid van de kwantoren om; een daaropvolgende ? keert die opnieuw om.
• R begint relatief ten opzichte van het einde van de laatste patroonmatch. U gebruikt gedecodeerde URI-buffers, B gebruikt geen gedecodeerde buffers.

Leg daarom vóór de pilot vast in welke buffer en vanaf welke positie het patroon moet gelden. Een correcte regex op ruwe gegevens hoeft niet te matchen op een gedecodeerde URI.

Binaire velden lezen: byte_test en byte_jump

byte_test leest een veld en controleert de numerieke waarde ervan. Het schema is byte_test:COUNT,[!]OPERATOR,VALUE,OFFSET[,relative][,big|little][,NUMBER_TYPE,string];. COUNT is het aantal gelezen bytes, OFFSET het beginpunt in de payload; met relative ligt het beginpunt relatief ten opzichte van de laatste patroonmatch. VALUE is de vergelijkingswaarde. Gedocumenteerd zijn <, >, =, ! en &: kleiner, groter, gelijk, ongelijk en bitsgewijze AND. Een ! vóór een vergelijkingsoperator keert het resultaat daarvan om. big of little bepaalt de bytevolgorde. Met string worden tekstuele cijfers gelezen in plaats van een binair getalveld; hex, dec en oct gelden alleen voor deze tekstmodus.

Voorbeeld voor een binair veld: byte_test:2,=,16,0,big; leest twee bytes vanaf payloadpositie 0 als Big Endian en vergelijkt die met 16. Aantal, positie, bytevolgorde en vergelijkingswaarde moeten uit het protocol komen, niet uit dit voorbeeld. Een willekeurige getalswaarde is geen bewijs van een aanval.

byte_jump leest daarentegen een lengte en verplaatst de positie voor volgende controles. Het schema is byte_jump:COUNT,OFFSET[,relative][,multiplier FACTOR][,big|little][,string][,hex|dec|oct][,align][,from_beginning];. De eerste twee operanden bepalen de veldbreedte en leespositie; relative maakt de offset relatief ten opzichte van de laatste patroonmatch. multiplier vermenigvuldigt de gelezen waarde voor de sprongafstand. align rondt deze naar boven af op de volgende 32-bitsgrens. Met from_beginning wordt de sprongafstand toegepast vanaf het begin van de payload in plaats van vanaf de huidige positie. string en de talstelsels hebben hetzelfde doel als bij byte_test.

byte_jump:2,0,big; is dus een fragment voor een lengteveld van twee bytes aan het begin van de payload met een expliciet gekozen bytevolgorde. Het is geen groottevergelijking; een vergelijkingsoperator en vergelijkingswaarde zijn geen operanden van byte_jump. Voor beide byte-sleutelwoorden wordt bij binaire velden van meerdere bytes expliciet big of little gekozen: vertrouw niet op een standaard-bytevolgorde die uit de documentatie is afgeleid. Controleer eerst het veld en de sprongbestemming aan de hand van de werkelijke testpayload en test daarna een positief en negatief geval voor de volgende voorwaarde. Een verkeerde lengte kan de zoekpositie voorbij het gewenste patroon laten springen.

IP-velden, opties en fragmenten

• ttl:64;, ttl:>64; en ttl:<64; vergelijken de IP Time to Live exact, hoger of lager dan een waarde. tos:16; vergelijkt het TOS-veld, id:1234; het IP-ID-veld. Deze voorbeeldgetallen zijn geen aanbevolen detectiewaarden; ze worden gekozen op basis van het werkelijk gezochte headerkenmerk.
• ipopts:rr; controleert op een aanwezige IP-optie. Toegestane waarden zijn 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) en any (een willekeurige IP-optie). any vereist dus een optie, niet zomaar een willekeurig IP-pakket.
• fragoffset:0; vergelijkt de fragmentoffset in de IP-header met een decimaal getal. Dit veld is niet de zoekoffset voor content in de payload.
• fragbits controleert M (More Fragments), D (Don’t Fragment) en R (Reserved). Een voorafgaande + staat naast de opgegeven bits andere bits toe, * vereist minstens één van de opgegeven bits en ! vereist dat de opgegeven bits niet zijn ingesteld. Zo controleert fragbits:+M; of More Fragments is ingesteld, zonder andere bits uit te sluiten.
• dsize:300;, dsize:>300;, dsize:<300; en dsize:300<>400; beschrijven een exacte payloadgrootte, een vergelijking met een boven-/ondergrens of een bereik. De getallen hebben betrekking op de payload van het pakket, niet op de volledige verbinding. De hierboven toegelichte beperkingen voor gereconstrueerde streams blijven gelden.
• ip_proto:6;, ip_proto:!6;, ip_proto:>6; en ip_proto:<6; vergelijken de numerieke protocolidentificatie in de IP-header, niet de TCP-/UDP-poort. samip; heeft geen waarde en vereist hetzelfde bron- en bestemmings-IP.

TCP-velden en streamselectie

flags controleert TCP-flags: S voor SYN, A voor ACK, F voor FIN, R voor RST, U voor URG en P voor PSH. Zonder modifier controleert bijvoorbeeld flags:S; op uitsluitend SYN. Een voorafgaande +, * of ! heeft de betekenis die hierboven bij fragbits is uitgelegd. flags:+S; staat daarom aanvullende flags toe. De hulp toont een optionele tweede groep flags na een komma, maar legt de vergelijkingssemantiek daarvan niet uit. Behandel flags:S,A; daarom niet als een bevestigde instructie om ACK te negeren; laat dit gedrag vóór gebruik voor de geïnstalleerde build ophelderen. Speciale gevallen voor gereserveerde TCP-bits en ‘geen flags ingesteld’ worden hier bewust niet als kopieerbare syntaxis aangeboden; ze vereisen een versiegebonden bevestigde regel en mogen niet uit een onduidelijk label worden afgeleid.

Voor flow zijn de eerder toegelichte richtingen en daarnaast established, no_stream en only_stream beschikbaar. flow:established; vereist een tot stand gebrachte TCP-verbinding. flow:no_stream; sluit gereconstrueerde streampakketten uit, flow:only_stream; beperkt de detectie tot deze pakketten. Deze fragmenten lichten de afzonderlijke keuzes toe en zijn geen instructie om beide streamopties samen te gebruiken. bi_direction blijft de hierboven beschreven uitbreiding naar heen- en retourverkeer.

seq:1234;, ack:1234; en window:4096; vergelijken respectievelijk het TCP-volgnummer, het bevestigingsnummer en de venstergrootte met een getal. Exacte volgnummers of ACK-waarden verschillen tussen verbindingen en zijn alleen zinvol als juist die waarde onderdeel is van de detectie. Het TCP-venster is geen zoekvenster voor de payload.

ICMP en RPC

itype:8; en icode:0; vergelijken ICMP-type en -code. Beide ondersteunen ook <, > en bereiken zoals itype:3<>5;; type en code zijn verschillende velden. icmp_id:1234; en icmp_seq:1; vergelijken de ICMP-identifier en volgnummerwaarde exact. De waarden worden gekozen op basis van het gewenste ICMP-geval, niet gelijkgesteld aan TCP-volgnummers.

rpc:100000,2,*; controleert in SUNRPC-CALL-verzoeken op toepassingsnummer 100000, versie 2 en een willekeurige procedure. Het schema is rpc:APPLICATION,VERSION,PROCEDURE;; * is toegestaan voor versie en procedure, niet voor het toepassingsnummer. De getallen worden vervangen door de gezochte toepassing, versie en procedure. Een wildcard maakt protocolanalyse niet overbodig: deze laat het betreffende deel bewust open en verbreedt daarmee de detectie.

Een signatuur aanmaken en aan een policy toewijzen

Onder Intrusion prevention > Custom IPS signatures > Add worden Name, Protocol, Custom rule, Severity en Recommended action ingesteld. Een naam zoals PILOT-TCP-8080-AVANET-TOKEN maakt het doel en de testgrenzen duidelijk. Severity beschrijft de eigen risico-inschatting; deze bewijst niet dat het patroon kwaadaardig is.

Voor de eerste uitvoering blijft Recommended action op Allow packet staan. Belangrijk: de actie van de IPS-policyregel overschrijft deze aanbeveling. Daarom moet ook de pilotregel Allow packet gebruiken. De overige acties hebben aanzienlijk ingrijpendere gevolgen:

• Drop packet verwijdert alleen het passende pakket.
• Drop session beëindigt de sessie na de match.
• Reset beëindigt een TCP-sessie en stuurt een reset naar de oorsprong.
• Bypass session staat het verkeer toe en controleert de rest van de sessie niet verder.

Bij sessiegebaseerde acties controleert SFOS alleen tot het eerste passende pakket. Voordat van Allow packet naar een dergelijke actie wordt overgeschakeld, moet daarom bevestigd zijn dat precies die eerste match betrekking heeft op de bedoelde sessie.

Bij het opslaan configureert SFOS de IPS-engine opnieuw. Als er voldoende vrij RAM beschikbaar is, gebeurt dit zonder onderbreking. Bij weinig vrij RAM kan de engine opnieuw starten en een korte onderbreking veroorzaken. Wijzigingen horen daarom ook bij een ogenschijnlijk kleine signatuur thuis in een tijdvenster waarin toezicht wordt gehouden. Controleer na het opslaan de IPS-status en ips.log op een herstart of fouten voordat de pilot wordt voortgezet.

Sla na deze voorafgaande controle de signatuur op met Save en open het item opnieuw: Protocol, Custom rule, Severity en Recommended action moeten overeenkomen met de geplande waarden. Laat Firewall Acceleration en PKI Acceleration tijdens de pilot ongewijzigd; elke in- of uitschakeling start IPS opnieuw en vertekent de vergelijking. Zonecontrole, Trusted MAC, IP-MAC-paren en DoS-uitzonderingen zijn afzonderlijke mechanismen onder DoS- en spoofingbescherming, geen eigenschappen van een Custom Signature.

Daarna volgt het vaak over het hoofd geziene tweede deel: open onder Intrusion prevention > IPS policies een policy die verwijderd mag worden en voor de pilot is bedoeld, voeg een regel toe, kies Custom signature, selecteer de signatuur en plaats de specifieke regel boven bredere regels. SFOS evalueert IPS-policyregels van boven naar beneden. Sla de policyregel op met Save en sla daarna ook de omvattende IPS Policy op met Save. Open de policy opnieuw en controleer de opgeslagen signatuurselectie en actie. Koppel deze policy vervolgens onder Rules and policies > Firewall rules > [Pilotregel] > Detect and prevent exploits (IPS) aan de pilotregel waarop het verkeer daadwerkelijk matcht; sla ook de firewallregel op en controleer met een nieuwe sessie.

Hetzelfde signatuurobject beheren via de XML API

Wie de pilot automatiseert, werkt met het XML-object IPSCustomSignature, niet met een IPS-policyregel. De SFOS-22/23-referentie noemt de bewerkingen Add Custom Signature, Update custom signature en Delete Custom Signature. Toegang, expliciete schrijfbewerking, back-up, antwoordbeoordeling en het stoppen bij een onduidelijke payload worden centraal toegelicht in XML API veilig gebruiken. Vóór het schrijven moeten de objectdefinitie en de bewerking in API help van de geïnstalleerde build zijn bevestigd; hier wordt geen aanvullend uitvoerbaar schrijfverzoek gegeven.

In het objectvoorbeeld staan Name, Protocol, CustomRule, Severity en RecommendedAction binnen IPSCustomSignature. Name duidt de signatuur aan, niet de policy of firewallregel. De parametertabel vereist hiervoor een scalaire string van maximaal 15 tekens; ook Delete vereist deze exacte naam. Kies voor API-automatisering daarom een korte, unieke naam zoals IPS-PILOT-8080. De langere WebAdmin-voorbeeldnaam hierboven is geen kopieervoorbeeld voor de API. Lees vóór Update of Delete de daadwerkelijk opgeslagen identiteit en alle policyverwijzingen uit, in plaats van het doel af te leiden uit een SID of een item met een vergelijkbare naam.

De tabel markeert alle vijf gegevens voor Add/Update als verplicht en scalair. Protocol staat TCP, UDP, ICMP of ALL toe; Severity staat Critical, Major, Moderate, Minor of Warning toe. CustomRule bevat de signatuurdefinitie als string. Het tabellabel Custom Rule met een spatie is niet de XML-schrijfwijze CustomRule. De aanvullende aanwijzing om letters met een punt te scheiden, verklaart noch een algemene regelconversie, noch XML-escaping. Wijzig de hierboven beschreven syntaxis daarom niet mechanisch met punten, maar controleer de regelinhoud en de juiste XML-codering voor de build. Het fabrikantvoorbeeld gebruikt alleen SignatureDefinition als placeholder; dat levert geen gebruiksklare signatuur op, noch een signatuur die aantoonbaar kwaadaardig verkeer herkent.

Verwar aanbeveling en actie niet: Het XML-voorbeeld gebruikt RecommendedAction, terwijl de parametertabel hetzelfde onderwerp Action noemt. Als tekstwaarden vermeldt deze Allow Packet, Drop Packet, Drop Session, Reset en Bypass Session, en daarnaast 3. Dit is geen bevestigde toestemming om RecommendedAction te vervangen door een XML-tag Action. Voor 3 wordt geen betekenis of koppeling aan een tekstactie uitgelegd; raad deze waarde niet en gebruik deze niet als afkorting voor een bepaalde actie. Lees de daadwerkelijk opgeslagen aanbeveling uit en controleer daarnaast nog steeds afzonderlijk de actie van de IPS-policyregel. Een aangemaakt API-object vervangt noch de policytoewijzing, noch de positieve en negatieve test.

API-antwoorden vergelijken met de bewerking en de opgeslagen toestand

De volgende regels zijn gedocumenteerd in de SFOS-22/23-objectreferenties. De Message.*-namen blijven onopgeloste documentatiesymbolen: het zijn geen gegarandeerde runtimeberichten, geen vertaalde foutteksten en geen definitief bevestigde oorzaken. Ook de getallen zijn XML-statuscodes, geen HTTP-statuscodes. Bewaar de bewerking, code en het daadwerkelijke antwoord samen; vervang de objectspecifieke regels niet door een algemene interpretatie van codes uit het centrale API-artikel.

Voor Add Custom Signature noemt de referentie:

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

Voor Update custom signature noemt deze:

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

Juist bij 504 verschilt het symbool tussen Add en Update; Message.CustomSigCustomSignatureCheck1 wordt niet geherinterpreteerd als een vermeend eenduidige syntaxisfoutmelding. Open vóór een nieuwe Add/Update het item opnieuw in WebAdmin of controleer het met een leesquery die voor de build is bevestigd: komen Name, Protocol, Custom rule, Severity en Recommended action overeen met de gewenste toestand? Vergelijk bij 502 de bestaande en gewenste identiteit; overschrijf niet automatisch en maak geen item onder een tweede naam aan. Vergelijk bij 504 daarnaast de exacte regel met de builddocumentatie. Controleer bij 505 de opgeslagen toestand, IPS-status en ips.log gezamenlijk; uit het symbool volgt noch een veilige rollback, noch toestemming om de engine opnieuw te starten. Controleer bij 506 de IPS- en licentiestatus zoals beschreven in het onderdeel over de levenscyclus, maar schakel IPS niet op goed geluk om. Ook na 200 moeten de opgeslagen waarden, de policykoppeling en het gegevenspad worden gecontroleerd; 500 bewijst niet dat er helemaal geen gedeeltelijke wijziging heeft plaatsgevonden.

Voor Delete Custom Signature zijn de volgende afzonderlijke regels gedocumenteerd:

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

Geef Delete pas vrij na de hieronder beschreven rollback en een volledige controle van het gebruik. Onderzoek bij 503 de policyverwijzingen naar het daadwerkelijke object; verwijder niet zonder meer een productie-policy. Held­er bij 506 de IPS- en licentiestatus op, in plaats van IPS globaal uit te schakelen voor een verwijderpoging. Lees na het antwoord uit of de exacte naam ontbreekt en of de afhankelijke policies de verwachte toestand hebben; verwijder bij 500 of een onduidelijk antwoord niet blind opnieuw. Als de opgeslagen toestand, het antwoord of de verantwoordelijkheid onduidelijk blijft, stop dan de automatisering en bespreek het opgeschoonde antwoord, de regelversie, build en logs met Sophos Support. Hier wordt niet beweerd dat runtimegedrag op een firewall is getest.

Een positieve en negatieve test uitvoeren

De positieve test verstuurt het afgesproken patroon via de beoogde poort en in de verwachte richting. Kies in Log Viewer, rechtsboven in WebAdmin, de IPS-module en filter op testtijd, Source en Destination. De signatuur of SID, actie en het tijdstip moeten bij de test passen. ips.log levert aanvullende enginedetails. Packet Capture onder Diagnostics > Packet capture toont daarnaast Firewall Rule ID en IPS Policy ID. Het verband tussen regel, Packet Capture en beveiligingsmodule wordt toegelicht in Een firewallregel systematisch testen.

Na de pilotfase kan de werking bovendien worden geëvalueerd onder Reports > Network & threats > Intrusion attacks. Het rapport is nuttig voor vergelijkingen tussen perioden, maar vervangt niet de tijdige positieve en negatieve test in Log Viewer.

Daarna volgt minstens één negatieve test: dezelfde dienst zonder token, een andere poort of een afwijkende richting. De signatuur mag daarbij niet matchen. Bij een contentpatroon zijn ook normale requests van de toepassing belangrijk, omdat korte of algemene strings in volkomen legitieme payloads kunnen voorkomen.

Pas wanneer beide tests stabiel zijn, wordt de geplande blokkerende actie ingesteld en opnieuw gecontroleerd. Een blokkerende signatuur geldt alleen als geaccepteerd wanneer precies het positieve geval wordt gestopt, het negatieve geval blijft werken en geen andere firewall- of IPS-regel het effect veroorzaakt.

Het aantal signaturen controleren

Het aantal kan in WebAdmin zonder shell worden bepaald. Open onder Intrusion prevention > IPS policies een policy die verwijderd mag worden en maak een nieuwe policyregel aan. Met Select all toont SFOS het totale aantal boven Action. De lijst is alleen zichtbaar bij het toevoegen van een regel aan een policy die verwijderd mag worden; het dialoogvenster kan daarna zonder opslaan worden gesloten.

Sophos documenteert daarnaast twee leesquery’s onder 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;"

De eerste opdracht telt de standaardsignaturen, de tweede de Custom Signatures. Deze databasequery’s wijzigen niets, maar horen thuis in een gedocumenteerde support- of diagnosesessie. Het aantal is geen bewijs van kwaliteit of werking en kan door patternupdates veranderen.

Per query wordt één resultaatregel onder count verwacht, gevolgd door (1 row). De Sophos-voorbeeldwaarden 28623 en 1 komen uit een SFOS-19.0.1-voorbeeld en zijn geen streefwaarden voor SFOS 22/23. Wijzig bij database-, verbindings- of machtigingsfouten geen tabellen of services: gebruik de WebAdmin-controle en bewaar de exacte uitvoer en build voor support.

Als de signatuur niet werkt zoals verwacht

Er is geen match

Controleer eerst of IPS actief is, het verkeer matcht op de verwachte firewallregel met de juiste IPS Policy en de Custom Signature daadwerkelijk in een geëvalueerde policyregel staat. Daarna volgen protocol, richting, poort, versleuteling en de werkelijke payload. Een string die in een browser wordt weergegeven, hoeft niet ongewijzigd in het netwerkpakket te staan.

Een nauw gefilterde Packet Capture is nuttig om richting, poort en de op dat capturepunt zichtbare inhoud te tonen. Een ontbrekend tekstpatroon in een versleutelde capture bewijst echter niet dat het in de ontsleutelde IPS-buffer ontbreekt. Controleer daarom capturepunt, ontsleuteling en streamreconstructie gezamenlijk. Voor een gecontroleerde test met platte tekst moet het daadwerkelijk verzonden patroon controleerbaar zijn; controleer daarna offset, depth, distance, within, de streamstatus en de volgorde van de policyregels.

Te veel verbindingen matchen

De signatuur blijft op Allow packet staan totdat Source, Destination, poort, richting of zoekvenster nauwer zijn afgebakend. Algemene woorden, korte binaire reeksen en onbegrensde reguliere expressies zijn typische oorzaken. Een brede firewallregel maakt de werking bovendien moeilijker beheersbaar.

Als de firewall na het opslaan een stijgend resourcegebruik of een IPS-herstart laat zien, bewaar dan het tijdstip, model, firmware, de vrije resources en ips.log. Herhaaldelijk verschillende varianten opslaan is dan geen zuivere test; bepaal eerst de oorzaak en spreek een onderhoudsvenster af.

Veilig terugdraaien

Bij onverwachte matches wordt eerst de Custom-regel uit de pilot-policy verwijderd of de eerdere IPS Policy op de firewallregel hersteld. Controleer daarna nieuwe sessies met een positieve en negatieve test. Verwijder de Custom Signature pas wanneer deze nergens anders meer wordt gebruikt.

Vóór het verwijderen moet worden vastgelegd welke policy, firewallregel en toepassing de signatuur hebben gebruikt. Logs, de geteste regelversie en de reden voor de rollback horen in de wijzigingsregistratie. IPS globaal uitschakelen of de volledige productie-policy verwijderen is geen passende rollback voor één foutieve signatuur.

FAQ